'sudo startxfce4' causes reboot

[WillCPP]

On the Acer c720 Version 41.0.2272.89 (64-bit), the most recent update to chrome os, I have trusty installed(my chroot is up to date as well). When I run the command 'sudo startxfce4' the chromebook restarts.

[xfanwu]

I have the same issue after I switched from the xiwi integration back to x11.

[midnightradio]

Just updated crouton and having the same issue, reboots on command "sudo startxfce4".

crouton: version 1-20150304145447~master:550afdb3 release: trusty architecture: amd64 xmethod: xorg targets: x11,keyboard,audio,cli-extra,xiwi,extension,touch,xfce host: version 6680.64.0 (Official Build) stable-channel link

[midnightradio]

By scanning down a few, my issue seems to be the same as #1474 with the same version of crouton, and there's a link to #1278 hopefully containing a workaround that I'm trying to catch. @javel , you should check it if you are in the same version.

[midnightradio]

I tried to roll back to crouton version (1-20150127081428~master:e1bcac2b) which had been used without rebooting until I updated few hours ago, but still the old crouton causes reboot when I run "startxfce4".

Now I wonder it is closely related to previous issue I mentioned above... #1474 seems to be more close to VirtualBox which I don't use. I guess recent update v41 having module_locking removed causing this problem. But still don't understand why didn't I faced this problem at the time of updating chromeos but experiencing reboot after updating crouton.

I'm very cautious in this because it's my working machine although I have backup (which I cannot trust fully) and I cannot try any solution that I don't understand what actually it does. I need some help. Please.

[tedm]

Is the tool you are using to output your version info. 3 posts up edit-chroot? If so, and I doubt this is the cause of your reboot issue, I think that just specifying xfce,xiwi would bring in the dependencies, and leave your defined target list smaller.

Have you tried setting xmethods to xiwi?

Are you prompted to continue running the script or does it just continue?

Since Chrome OS updates can happen automatically, I would keep your data offline on removable media (USB 3 flash drives are very fast), so you can just rebuild your chroots when needed, as there is no simple way to revert.

[divx118]

1474 is indeed related to virtualbox and has nothing to do with the issue mentioned here. Also the issue mentioned here is in no way related to the removal of the sysfs module_locking. Like @tedm mentioned, try xiwi and see if it is not rebooting anymore. Just to narrow down the cause of the reboot.

Also posting the output of /dev/pstore/console-ramoops could be useful.

[midnightradio]

@tedm The version info from "croutonversion". And I was not using xiwi but X11. I had tried xiwi a month ago but put X11 at the front since X11 gives better usage to me. I don't know what xmethods is but I'll try as soon as xiwi becomes available again. Lastly, I'm sad about my Pixel(1st) does not have USB3.0 interface.

@divx118 I was trying with xiwi an hour ago, but faced another failure with a following error and cannot narrow down.

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

And, the file /dev/pstore/console-ramoops not exist.

[tedm]

@midnightradio since it appears you have xiwi as a target, try:

appending -X xiwi to your start* line or set env exec XMETHODS=xiwi

I don't think the order that your targets are in the file have any effect on what starts.

If offline, you can use ~/Downloads and access that data from outside the chroot, but it's not recommended, as it may not always be permanent storage.

[midnightradio]

@tedm In practice, when x11 positioned before xiwi, the desktop environment runs in classic way and vice versa. I just tried your advice and confirmed that it is the same as I wrote above by updating the target "xiwi" and putting it front position. (Anyway, good to know that there's a simple way to run X11 without updating the target.) As you see, xiwi cannot be a workaround due to another error, "Cannot open /dev/tty0". Of course I'm working it hoping that I can continue my work again, but I think the newly introduced problem on xiwi is irrelevant to this. Thanks for your help, anyway.

[tedm]

@midnightradio Thanks for this info. I hope you get running soon.

Can you clarify what you mean by the target position in the front position having priority or running by default?

I just put xiwi in front of my xephyr target in /etc/crouton/targets and my default xmethod is still xephyr:

chronos@localhost /etc $ sudo edit-chroot -al name: precise encrypted: no Entering /mnt/stateful_partition/crouton/chroots/precise... crouton: version 1-20150301132939~master:80da699e release: precise architecture: armhf xmethod: xephyr targets: xiwi,xephyr,xfce host: version 6457.107.0 (Official Build) stable-channel daisy Unmounting /mnt/stateful_partition/crouton/chroots/precise...

[tedm]

@midnightradio OK, this is a long shot, but have you tried removing/purging any/all screensavers in your chroot?

[midnightradio]

@tedm I've never edited the file /etc/crouton/targets but only put the target prior to others by running command "crouton" with -u and -t. For example, when you run "crouton -u -t x11 -n name" you will get x11 at the front. Also, I've never used any screensaver which has been notorious for something bad. Thanks for developing the issue. I really need a solution...

[tedm]

@midnightradio OK, I answered my own question above about the ordering, after updating -t xfce -u, (all targets in /etc/crouton/targets get updated with -u), the order now has xiwi ahead of xephyr, and xiwi as xmethod (though I can override with -X xephyr on start* command line).

Have you tried creating a chroot with just xfce, letting crouton pick the fastest xmethod and letting crouton install x11? (and xiwi if you want), all of your targets will still be there when you're done, just look at /.crouton-targets when done, or if encrypted, from outside the chroot.

By doubling up on manually specifying each of these, and then crouton having to figure out what is already installed vs what it needs to install as a dependency, could be borking your system.

chronos@localhost / $ sudo edit-chroot -al name: precise encrypted: no Entering /mnt/stateful_partition/crouton/chroots/precise... crouton: version 1-20150304145447~master:550afdb3 release: precise architecture: armhf xmethod: xiwi targets: xfce,xiwi,xephyr host: version 6680.64.0 (Official Build) stable-channel daisy Unmounting /mnt/stateful_partition/crouton/chroots/precise...

[stephenlewis]

I also see the 'instant reboot when starting X' - I think this is the relevant part of /dev/pstore/console-ramoops, taken on my (original) Pixel:

$ croutonversion 
crouton: version 1-20150304145447~master:550afdb3
release: trusty
architecture: amd64
xmethod: xorg
targets: keyboard,unity,touch,chrome
host: version 6680.64.0 (Official Build) stable-channel link 

[   84.996044] BUG: unable to handle kernel NULL pointer dereference at 0000000000000074
[   84.996089] IP: [<ffffffffb66c8206>] intel_crtc_page_flip+0x33/0x315
[   84.996129] PGD 0 
[   84.996157] Oops: 0000 [#1] SMP 
[   84.999991] gsmi: Log Shutdown Reason 0x03
[   84.999999] Modules linked in: i2c_dev uinput snd_hda_codec_hdmi aesni_intel xts memconsole snd_hda_codec_ca0132 aes_x86_64 lrw gf128mul ablk_helper cryptd snd_hda_intel snd_hda_codec zram(C) snd_hwdep snd_pcm lzo_compress snd_page_alloc isl29018(C) zsmalloc(C) fuse snd_timer nm10_gpio industrialio nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter ip6_tables ath9k_btcoex ath9k_common_btcoex ath9k_hw_btcoex ath mac80211 cfg80211 ath3k uvcvideo btusb videobuf2_vmalloc bluetooth videobuf2_memops videobuf2_core videodev joydev ppp_async ppp_generic slhc tun
[   85.000256] CPU 2 
[   85.000267] Pid: 18164, comm: Xorg Tainted: G         C   3.8.11 #1
[   85.000282] RIP: 0010:[<ffffffffb66c8206>]  [<ffffffffb66c8206>] intel_crtc_page_flip+0x33/0x315
[   85.000304] RSP: 0018:ffff8801414f3cb8  EFLAGS: 00010286
[   85.000316] RAX: ffff88014518aa00 RBX: ffff880147bc3200 RCX: 0000000000000201
[   85.000329] RDX: ffff8800a7968660 RSI: ffff88008fd77240 RDI: ffff88014aab6000
[   85.000340] RBP: ffff8801414f3d00 R08: ffff88008fd77240 R09: 0000000000000030
[   85.000352] R10: 0000000000000000 R11: ffffffffb6690ced R12: ffff88014aab5000
[   85.000364] R13: ffff88014aab6000 R14: 0000000000000000 R15: ffff88014a2c0000
[   85.000378] FS:  00007f05b131e9c0(0000) GS:ffff88014f300000(0000) knlGS:0000000000000000
[   85.000391] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[   85.000403] CR2: 0000000000000074 CR3: 000000011d2c9000 CR4: 00000000001407e0
[   85.000415] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[   85.000427] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[   85.000442] Process Xorg (pid: 18164, threadinfo ffff8801414f2000, task ffff88012e077080)
[   85.000454] Stack:
[   85.000462]  ffffffffb669d776 ffff88008fd77240 0000000000000030 ffff88008fd77240
[   85.000489]  ffff880147bc3200 ffff88014a26e600 ffff88014aab6000 ffff880147bc3e00
[   85.000514]  ffff880147bc3400 ffff8801414f3d48 ffffffffb669dcef 0000000000000000
[   85.000540] Call Trace:
[   85.000554]  [<ffffffffb669d776>] ? commit_crtc_state+0x3e/0x21c
[   85.000579]  [<ffffffffb669dcef>] commit_plane_state+0x215/0x280
[   85.000591]  [<ffffffffb669d482>] atomic_commit.isra.3+0x93/0xb4
[   85.000601]  [<ffffffffb669d4b4>] drm_atomic_commit+0x11/0x13
[   85.000611]  [<ffffffffb66963e2>] drm_mode_page_flip_ioctl+0x1bd/0x230
[   85.000621]  [<ffffffffb6686006>] drm_ioctl+0x2f5/0x3d2
[   85.000629]  [<ffffffffb6696225>] ? drm_mode_gamma_get_ioctl+0xc7/0xc7
[   85.000640]  [<ffffffffb65de5ae>] ? timerqueue_del+0x52/0x5a
[   85.000650]  [<ffffffffb6453171>] ? __remove_hrtimer+0x34/0x8d
[   85.000660]  [<ffffffffb64536fe>] ? hrtimer_try_to_cancel+0x95/0xb5
[   85.000669]  [<ffffffffb64f7eeb>] do_vfs_ioctl+0x362/0x425
[   85.000678]  [<ffffffffb64f88e7>] ? poll_select_copy_remaining+0xf5/0x120
[   85.000686]  [<ffffffffb64f801b>] sys_ioctl+0x6d/0xa5
[   85.000696]  [<ffffffffb68ba502>] system_call_fastpath+0x16/0x1b
[   85.000703] Code: e5 41 57 41 56 41 55 41 54 53 48 83 ec 20 48 8b 87 b8 00 00 00 4c 8b 27 4c 8b 70 50 48 8b 86 90 00 00 00 4d 8b bc 24 f0 03 00 00 <41> 8b 5e 74 39 5e 74 48 89 45 d0 b8 ea ff ff ff 0f 85 bd 02 00 
[   85.000883] RIP  [<ffffffffb66c8206>] intel_crtc_page_flip+0x33/0x315
[   85.000895]  RSP <ffff8801414f3cb8>
[   85.000901] CR2: 0000000000000074
[   85.000941] ---[ end trace 08cbcbe56779f4ed ]---
[   85.006069] Kernel panic - not syncing: Fatal exception
[   85.006084] Kernel Offset: 0x35400000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff)
[   85.006227] gsmi: Log Shutdown Reason 0x02
[   85.011367] ACPI MEMORY or I/O RESET_REG.

[picostove]

I'm about to file a kernel bug for this, but if you're experiencing this issue can you check whether or not you're using freon (the new X-less way of running Chrome)?

The easiest way to check is to open VT2 (CTRL + ALT + Forward/F2). If you see the text "Welcome to frecon!" at the top, you're using freon. You can return to Chrome with CTRL + ALT + Previous/F1.

[stephenlewis]

@smibarber I am experiencing the issue, and I don't see that text on VT2.

[picostove]

Thanks! Upstream bug filed: https://code.google.com/p/chromium/issues/detail?id=466774

As always, if you want to follow the issue feel free to star it, but please keep commentary and discussion on Github.

[phucng]

I got the same issue with sudo startlxde (causing reboot) after updating crouton.

I'm running trusty with LXDE on a HP Chromebook 14. Everything is fine after updating ChromeOS and before updating crouton.

Someone at https://plus.google.com/102016847086903746448/posts/JfYjzwwr5TT?cfem=1 said that xiwi might help. I installed the extention and tried to add xiwi, yet I got the following error:

Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation:

The following packages have unmet dependencies: xserver-xorg-dev : Depends: mesa-common-dev E: Unable to correct problems, you have held broken packages. Failed to complete chroot setup.

[WillCPP]

I had tried using xiwi with the extension, no luck what fixed the issue for me was found here

https://github.com/dnschneid/crouton/issues/1265

specifically i used the command

sudo CROUTON_BRANCH=x11_freon sh ~/Downloads/crouton -t xfce -n trusty -u

this switched the branch and updated my chroot and works with chrome os Version 41.0.2272.89 (64-bit)

That is the current fix for the issue I was having.

[picostove]

Please leave this open until the root cause is identified. x11_freon is a dead branch that's been merged into master, so you'll want to move off of it once this is fixed. It's a good data point that it works though, should help with finding the root cause.

[pankajmore]

How do I run : sudo CROUTON_BRANCH=x11_freon sh ~/Downloads/crouton -t xfce -n trusty -u ?

I get : /tmp/crouton-installer-cache/crouton-x11_freon: 1: {error:Not Found}: not found

On Fri, Mar 13, 2015 at 4:49 AM, Stephen Barber notifications@github.com wrote:

Please leave this open until the root cause is identified. x11_freon is a dead branch that's been merged into master, so you'll want to move off of it once this is fixed. It's a good data point that it works though, should help with finding the root cause.

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

[midnightradio]

@tedm Regarding to your suggestion, I installed another chroot with just xfce, and could successfully ran startxfce4 on that chroot. chroot named "trusty" is the one making me sad and the later "trusty-xfce" is the new.

chronos@localhost / $ sudo edit-chroot -al
name: trusty
encrypted: yes, unlocked
Enter encryption passphrase for trusty: 
Entering /mnt/stateful_partition/crouton/chroots/trusty...
crouton: version 1-20150304145447~master:550afdb3
release: trusty
architecture: amd64
xmethod: xorg
targets: x11,xiwi,keyboard,audio,cli-extra,extension,touch,xfce
host: version 6680.64.0 (Official Build) stable-channel link 
Unmounting /mnt/stateful_partition/crouton/chroots/trusty...
name: trusty-xfce
encrypted: no
Entering /mnt/stateful_partition/crouton/chroots/trusty-xfce...
crouton: version 1-20150304145447~master:550afdb3
release: trusty
architecture: amd64
xmethod: xorg
targets: xfce
host: version 6680.64.0 (Official Build) stable-channel link 
Unmounting /mnt/stateful_partition/crouton/chroots/trusty-xfce...
chronos@localhost / $ 

[tedm]

@midnightradio interesting. I am not really sure what's going on here, but your new chroot seems to have been installed in a cleaner manner, in that you only specified xfce, and let Crouton bring in the dependent targets.

Are you able to enter-chroot to recover your data from your first chroot, and move it to the newly created one?

[midnightradio]

@tedm Thanks again for responding. I cannot think of moving only data from first chroot to the other because it's almost impossible to move all environmental dependencies that I have had for my work, such like compiler libraries and other preferences.

Anyway, with the other chroot newly installed only with a target xfce, I could successfully run startxfce4 on xorg as a default, as I mentioned earlier. After that, I became curious about what happens on "xiwi" with the new chroot as I had trouble with old chroot getting an error "Cannot open /dev/tty0". So I added the target "xiwi" on the new chroot and there was no problem running xfce on xiwi either. Then I just added one more target "unity" with no reason but just for fun, and "xiwi" on new chroot started to show the same error, "Cannot open /dev/tty0", but startunity/startxfce are still work with xorg.

This odd happenings may not be relevant to the rebooting issue, but there must be some conflicts between targets. I wonder if I can remove all the targets I had installed at once and start to add one by one again.

[tedm]

@midnightradio I hope that your testing can help the developers in some way. There have been a couple of requests to have a frozen stable "crouton" but those feature requests got closed, either due to design or resource issues, or the fact that if ChromeOS has a rolling release that is difficult to downgrade, then you can't just tarball one part, you basically have to image your drive. I used to use Arch a lot, and still occasionally use it either stand alone or with Manjaro, but the rolling releases (Pacman -Syu) will kill me about 5% of the time and cause a lot of reverting. Crouton, fortunately has a larger testing base, but as we can see, it still doesn't eliminate all needs to revert, since the ChromeOS updates are frequent, and sometimes quirky... I also wish ChromeOS would provide an option (even if in dev mode only) where one could select when to update, so if things were working fine, and the updates weren't security or data loss related, I could wait for a long weekend... I hope you can get your chroot running, but I don't know of a way to selectively just remove unity or specific targets from an existing chroot,.

[tedm]

@midnightradio You may want to ask Maurice @divx118 @drinkcat or @DennisLfromGA if editing the /etc/crouton/targets and/or the /.crouton-targets and then doing an update will sort of remove or change priority of a target associated with a chroot after doing an -u upgrade. Or if your 2nd chroot is just a test chroot, maybe just give it a try...

[tedm]

@midnightradio another couple of long shots you might want to try - have you tried plugging a 2nd display into your system? What happens if you try to start your chroot with xephyr (might have to add it first), then startxfce4 -n [chrootnamethatwontopen] -X xephyr ?

[midnightradio]

@tedm I feel guilty for bothering others by commenting irrelevant things, but I think I found something presumably help people.

The error, "Cannot open /dev/tty0", on running xiwi was not caused by a conflict between targets but caused by a configuration file, /usr/share/X11/xorg.conf.d/10-monitor.conf which I have kept for customizing screen resolution. I found that xiwi refers to /etc/X11/xorg-dummy.conf while other XMETHODs don't. So I simply removed the file and I could run both startxfce4 and startunity over xiwi.

Now I can continue with my work. Thanks!

UPDATE: @tedm I forgot to mention that I had created the file 10-monitor.conf just before I added unity and though the error was caused by adding the target.

[tedm]

@midnightradio Wow, glad you got it running!! That's odd, since I thought xorg and xiwi were working on your test chroot, until you added the unity target? I think the xorg-dummy.conf file was needed to keep updates from breaking, and the ARM systems never ran xorg, only xephyr and xiwi, soon to be xiwi on freon, no xephyr.

[picostove]

Try running sudo apt-get install --reinstall xserver-xorg-core in your affected chroots. I think the fix for #1450 is at fault, but weirdly only for upgraded chroots.

[midnightradio]

@smibarber That worked! Thanks.

UPDATE: Also, I tried to reproduce the rebooting problem by updating x11 and startxfce4 reboots again.

[stephenlewis]

@smibarber reinstalling xserver-xorg-core confirmed working here too - thanks.

[tromso]

how do I 'sudo apt-get install --reinstall xserver-xorg-core'? I get 'sudo: apt-get: command not found'. I have the same problem when I type sudo startxfce4 my chromebook restarts. I have the C720 and I have upgraded from precise to trusty.

[DennisLfromGA]

@tromso - 'apt-get' should be done from inside your chroot - 1st - Enter sudo enter-chroot 2nd - Enter sudo apt-get install --reinstall xserver-xorg-core

[tromso]

@DennisLfromGA that fixed it, thank you so much, I was about to powerwash when you wrote.

[DennisLfromGA]

Cool! Glad I could help. ;)

[phucng]

@smibarber @DennisLfromGA: sudo apt-get install --reinstall xserver-xorg-core worked. Thank you!

[DennisLfromGA]

Thanx for the fix @smibarber, it looks like a winner.

[xfanwu]

Thank you @smibarber, the startxfce4 back to work! But I am no longer able to switch between ChromeOS and xfce via Ctrl+Alt+Shift+Back/Forward. How to fix this, any idea?

[belzecue]

Hi, Folks. A Crouton update hosed my Trusty. Hopefully this topic is the right place to post. First, my specs:

---

ASUS Chromebox Version 41.0.2272.76 (64-bit) Platform 6680.58.0 (Official Build) stable-channel panther Firmware Google_Panther.4920.24.26

My chroot: NOTE: this is from a backup subsequently restored after my attempted update earlier today, which resulted in the same startxfce-reboot behaviour described at the top of this topic.

name: trusty encrypted: no Entering /media/removable/chroots2/main/chroots/trusty... crouton: version 1-20150127081428~master:e1bcac2b release: trusty architecture: amd64 targets: xfce

host: version 6680.58.0 (Official Build) stable-channel panther

I received the ChromeOS 41 update about a week ago, maybe more, and I expected it to break crouton (thanks to the Freon changes) but it didn't. Everything continued to work fine without requiring me to update Crouton or do any maintenance.

Today I decided to update Crouton. Crouton ran its update without issue. Then when attempting to boot into Trusty I got the dreaded hard crash/reboot issue.

I immediately restored from a backup taken yesterday. I can now boot into Trusty, but the graphics are busted: I get to the desktop but then everything is almost entirely frozen or at least hugely laggy other than the mouse cursor which is unaffected. So I'm unable to run what might be the fix of "sudo apt-get install --reinstall xserver-xorg-core" because I can't paste that into a terminal, due to the extreme graphical lag.

What I would like to do is run an old Crouton update rather that the current one that breaks my Trusty, e.g. go back to "version 1-20150127081428~master:e1bcac2b" which I know worked just fine. I'm happy to do a powerwash if need be.

Can I get instructions on how to revert to an earlier version of Crouton, thanks!

EDIT: Uh oh. From this comment, seems rolling back won't fix it? https://github.com/dnschneid/crouton/issues/1490#issuecomment-78447261

[midnightradio]

Hi @belzecue , is your graphics problem looks like following? I had captured this when I was having the problem and fortunately got recovered.


chronos@localhost / $ sudo sh ~/Downloads/crouton -u -n trusty
Password: 
/usr/local/chroots/trusty already exists; updating it...
Preparing chroot environment...Previously installed target
'ï¿1⁄2ï¿1⁄2Plï¿1⁄2cß ̧C]yï¿1⁄2ï¿1⁄2ï¿1⁄2â�‹Û1⁄4Aï¿1⁄2┤â”1⁄42ï¿1⁄2.·âŽoâŽoï¿1⁄2\+ï¿1⁄2ï¿1⁄24ï¿1⁄2£ï¿1⁄2ï¿1⁄2Sï¿1⁄2Q Ë”ï¿1⁄2>' â”1⁄4âŽo ┌âŽoâ”1⁄4±â�ŠâŽ1⁄4 â�Šâ”‚â�‹âNâŽo ├▒âŽ1⁄4±â�Šâ”œ ┌â�‹âŽ1⁄2├ °âŽo┤â”1⁄4â�� (≤âŽoâ�Œâ�¤âŽ1⁄4âŽoâŽo├ └▒≤ â�‰â�Š â” ́â�ŠâŽ1⁄4≤ âŽo┌âP┌â�Šâ–’âŽ1⁄2â�Š âŽ1⁄2⎻â�Šâ�Œâ�‹Â°â‰¤ ├▒âŽ1⁄4±â�Šâ”œâ”¬â�‹â”œâ�¤ -├.
â�Œâ�¤âŽ1⁄4âŽoâ”1⁄4âŽoâŽ1⁄2@┌âŽoâ�Œâ–’┌â�¤âŽoâŽ1⁄2├ /

[belzecue]

@midnightradio No, the Crouton update I performed earlier today completed normally and without issue. There was no corruption/garbage in the command window like what you posted.

[tedm]

@belzecue can you sudo enter-chroot and run:

sudo apt-get install --reinstall xserver-xorg-core

from a crosh shell terminal without bringing up a graphical desktop of your chroot?

[belzecue]

@tedm Just now I was able to log in to terminal via enter-chroot and run the reinstall, which completed without issue. But when I boot into Trusty (xfce) it exhibits the same issue: top half of screen paints, then bottom half paints half a second later, and I see my usual desktop. Mouse is working normally. However, clicking on any graphical element causes a long delay before it appears, and then everything basically freezes other than the mouse. All I can do at that point is switch back to ChromeOS.

[tedm]

@belzecue what is your xmethod? edit-chroot -al will show it. Have you tried adding the xiwi target? Updating the chroot?

[belzecue]

Yes, chroot is up to date.

Based on discussion in: https://plus.google.com/+FrancoisBeaufort/posts/JDVkXALPcNq

I ran: sudo sh ~/Downloads/crouton -u -r trusty -t xiwi,xfce

which updated my Trusty chroot.

Now, typing: sudo startxfce4 -c /media/removable/chroots2/main/chroots

gives...

---

Entering /media/removable/chroots2/main/chroots/trusty... /usr/bin/startxfce4: Starting X server

X.Org X Server 1.15.1 Release Date: 2014-04-13 X Protocol Version 11, Revision 0 Build Operating System: Linux 3.2.0-76-generic x86_64 Ubuntu Current Operating System: Linux localhost 3.8.11 #1 SMP Mon Mar 2 06:44:29 PST 2015 x86_64 Kernel command line: cros_secure console= loglevel=7 init=/sbin/init cros_secure oops=panic panic=-1 root=/dev/dm-0 rootwait ro dm_verity.error_behavior=3 dm_verity.max_bios=-1 dm_verity.dev_wait=1 dm="1 vroot none ro 1,0 2506752 verity payload=PARTUUID=88f8160b-af43-3a47-9f41-4619d12b570f/PARTNROFF=1 hashtree=PARTUUID=88f8160b-af43-3a47-9f41-4619d12b570f/PARTNROFF=1 hashstart=2506752 alg=sha1 root_hexdigest=741ce042d3b8474b67d4a226473443a361c9ad05 salt=a5244d04421135d9c9dcaa10bc5213664528aaf0c8743b167039eabaad46a108" noinitrd vt.global_cursor_default=0 kern_guid=88f8160b-af43-3a47-9f41-4619d12b570f add_efi_memmap boot=local noresume noswap i915.modeset=1 tpm_tis.force=1 tpm_tis.interrupts=0 nmi_watchdog=panic,lapic
Build Date: 12 February 2015 02:49:29PM xorg-server 2:1.15.1-0ubuntu2.7 (For technical support please see http://www.ubuntu.com/support) Current version of pixman: 0.30.2 Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (++) Log file: "/tmp/Xorg.crouton.1.log", Time: Sun Mar 15 15:24:08 2015 (++) Using config file: "/etc/X11/xorg-dummy.conf" (==) Using system config directory "/usr/share/X11/xorg.conf.d" Initializing built-in extension Generic Event Extension Initializing built-in extension SHAPE Initializing built-in extension MIT-SHM Initializing built-in extension XInputExtension Initializing built-in extension XTEST Initializing built-in extension BIG-REQUESTS Initializing built-in extension SYNC Initializing built-in extension XKEYBOARD Initializing built-in extension XC-MISC Initializing built-in extension SECURITY Initializing built-in extension XINERAMA Initializing built-in extension XFIXES Initializing built-in extension RENDER Initializing built-in extension RANDR Initializing built-in extension COMPOSITE Initializing built-in extension DAMAGE Initializing built-in extension MIT-SCREEN-SAVER Initializing built-in extension DOUBLE-BUFFER Initializing built-in extension RECORD Initializing built-in extension DPMS Initializing built-in extension Present Initializing built-in extension DRI3 Initializing built-in extension X-Resource Initializing built-in extension XVideo Initializing built-in extension XVideo-MotionCompensation Initializing built-in extension SELinux Initializing built-in extension XFree86-VidModeExtension Initializing built-in extension XFree86-DGA Initializing built-in extension XFree86-DRI Initializing built-in extension DRI2 Loading extension GLX Unable to set master xf86: found device 0 /usr/bin/xinit: XFree86_VT property unexpectedly has 0 items instead of 1 Error: not connected. Cannot connect to extension, retrying... Error: not connected. Cannot connect to extension, retrying... Error: not connected. Cannot connect to extension, retrying... Error: not connected. Cannot connect to extension, retrying... Error: not connected. Cannot connect to extension, retrying... Error: not connected. Cannot connect to extension, retrying... Error: not connected. Cannot connect to extension, retrying... Error: not connected. Cannot connect to extension, retrying... Error: not connected. Cannot connect to extension, retrying... Error: not connected. Cannot connect to extension, retrying... Unable to start display, make sure the crouton extension is installed and enabled, and up to date. (download from http://goo.gl/OVQOEt) Running exit commands... /usr/bin/xinit: connection to X server lost

waiting for X server to shut down Hangup Hangup Hangup (EE) Server terminated successfully (0). Closing log file.

Unmounting /media/removable/chroots2/main/chroots/trusty... Sending SIGTERM to processes under /media/removable/chroots2/main/chroots/trusty...

---

sudo edit-chroot -al name: trusty encrypted: no Entering /mnt/stateful_partition/crouton/chroots/trusty... crouton: version 1-20150304145447~master:550afdb3 release: trusty architecture: amd64 xmethod: xiwi targets: xiwi,xfce host: version 6680.58.0 (Official Build) stable-channel panther Unmounting /mnt/stateful_partition/crouton/chroots/trusty...

[tedm]

@belzecue do you have the chrome Crouton extension installed from the web store?

[midnightradio]

EDIT : SORRY, SEEMS I WROTE THIS IN WRONG CONTEXT. NOW I FOUND THAT YOU ALREADY DID SO BUT STILL IN TROUBLE. GOOD LUCK.

@belzecue , I can see that you provided another chroot information while you put log messages for startxfce4 running on the chroot stored in removable disk. Option "-a" show only chroot stored in "/mnt/.../chroots", so you may specify the removable disk by giving option "-c" to edit-chroot or first enter-chroot then run croutonversion. Ah, but your only option is edit-chroot since your current state does not effectively allow you to enter-chroot,..

But I also can see that you have up-to-date version of crouton. Actually, what you have done with restoring the backup was different from what I did, which turned out not resolving the rebooting issue but at least it was enough to give normal usage after entering chroot. What I actually did was downloading old crouton (https://github.com/dnschneid/crouton/commits/releases/crouton) and running the update without restoring my backup chroot. Maybe you can try in the same way. You may experience the rebooting issue again, but at least you can run some commands after entering chroot. And this time, better not to follow #1474 but just reinstall "xserver-xorg-core".

[belzecue]

Ah, I did not have the chrome Crouton extension installed. https://chrome.google.com/webstore/detail/crouton-integration/gcpneefbbnfalgjniomfjknbcgkbijom

To recap today's events:

• updated Crouton, which broke my Trusty chroot with the hard-crash/reboot upon entering chroot
• restored chroot from a backup
• entered chroot terminal then: sudo apt-get install --reinstall xserver-xorg-core
• added 'xiwi' target to my chroot: sudo sh ~/Downloads/crouton -u -r trusty -t xiwi,xfce
• installed Crouton extension from Chrome web store
• chroot now successfully runs in a Chrome tab: sudo startxfce4 -b -c /media/removable/chroots2/main/chroots

That's great -- to at least have it up and running again. But does this mean I can't run it in its own x11 session any more? Running it in a Chrome tab feels a bit sluggish.

[Watney]

@belzecue have you tried adding -X xorg at the end of your start-up command?