Method http has died unexpectedly during software installation

[sidamos]

name: precise
encrypted: yes, locked
Unmounting /media/removable/SD/chroots/precise...
name: trusty
encrypted: yes, locked
Unmounting /media/removable/SD/chroots/trusty...

Please describe your issue:

I have an Acer Chromebook R11, running stable channel Chrome 51.
I had no problems installing precise and installing additional software.
Last week, I wanted to install trusty and always got the mentioned error after crouton was installing software for a while. Tried several times with -u and from scratch. No chance.
I tried a different mirror, but that did not help either.
This week, crouton was able to install trusty with no errors, using the default mirror.
However, when I try to install some packages (for example mesa-utils) inside xfce4 (shell window), I get that error again.
So, I logged out of xfce4 and started chroot console only and there I can install everything.

If known, describe the steps to reproduce the issue:

Install trusty
enter-chroot -n trusty startxfce4
start shell window
apt-get install mesa-utils

[sidamos]

Same with sudo apt-get install mono-complete
Got the http error when running in a shell window under xfce4.
Worked fine in Chrome OS shell in chroot.

[sidamos]

It seems, it also happens in the Chrome OS shell. Just tried to install x2goclient:
E: Method http has died unexpectedly!
E: Unterprozess http hat einen Speicherzugriffsfehler empfangen.

(segmentation fault)

[pjchamberlain]

Same issue on Acer R11
Version 53.0.2785.36 beta (64-bit)
Platform 8530.35.0 (Official Build) beta-channel cyan
ARC Version 3102164
Firmware Google_Cyan.7287.57.64

I was able to install a few packages normally from a terminal in xfce before this issue kicked in, since then it has remained. As said above no issue in Chrome OS shell from a chroot

[pjchamberlain]

latest update fixed this issue for me

Version 53.0.2785.47 beta (64-bit)
Platform 8530.43.0 (Official Build) beta-channel cyan
ARC Version 3117197
Firmware Google_Cyan.7287.57.64

[evelant]

This just started happening to me as well. On my acer chromebook R11.

I installed crouton with -t xfce,xorg,chrome,xiwi and everything was fine at first. I installed some software no problem then suddenly this started happening seemingly out of nowhere.

Version 53.0.2785.70 beta (64-bit)
Platform 8530.62.0 (Official Build) beta-channel cyan
ARC Version 3152187
Firmware Google_Cyan.7287.57.64

[evelant]

I got it working again, but I am not sure why it works. Here is what I did:

Went to http://packages.ubuntu.com/trusty/amd64/apt/download
Downloaded apt_1.0.1ubuntu2.13_amd64.deb
sudo dpkg -i apt_1.0.1ubuntu2.13_amd64.deb
Was warned about a downgrade from 1.0.1ubuntu2.14
apt-get works again

For some reason 1.0.1ubuntu2.14 seems to be broken.

[evelant]

Hmm, even stranger. The issue came back after I unmounted and remounted my chroot. Reinstalling apt fixed it again. It seems that apt is somehow being corrupted.

[pjchamberlain]

after the last Chrome update
Version 53.0.2785.103 beta (64-bit)
Platform 8530.81.0 (Official Build) beta-channel cyan
ARC Version 3251841
Firmware Google_Cyan.7287.57.82

when I run crouton -u I'm seeing this error

E: Method https has died unexpectedly!
E: Sub-process https received a segmentation fault.

ending up with
Failed to complete chroot setup.
Unmounting /mnt/stateful_partition/crouton/chroots/trusty...
Sending SIGTERM to processes under /mnt/stateful_partition/crouton/chroots/trusty...

if I try to enter-chroot I get

A chroot setup script still exists inside the chroot.
The chroot may not be fully set up.
Would you like to finish the setup? [Y/n/d] n
Skipping setup. You will be prompted again next time.

If I choose n or d .. I can enter the chroot and run apt-get update or upgrade fine without any errors

[pjchamberlain]

Update - seems to have been an issue with that particular chroot. I've created a new one which works fine. I've now realised the value of backing them up..

[pjchamberlain]

Issue has returned again for me after doing a crouton update

[RafaelGreenblatt]

I have had similar errors, also on a Chromebook R11, but with beta channel Chrome v53.0.2785.129. The problem comes and goes, eg if I exit and then restart the chroot the problem often goes away (but so far it always comes back later).

[kjleitz]

Just so I might get some responses without everyone having to read this enormous post:

• Is everyone who has this issue using an Acer R11?
• Does everyone who has this issue only have 2GB of RAM?
• Does anyone with the 4GB version of the R11 have this issue?

Anyway, on to the issue:

Same issues here on Trusty. I installed Precise a while ago with no issues (that I recall, but I wasn’t paying much attention so I can’t say for certain), and used it for a few weeks, but I ended up powerwashing. I did a Trusty install pretty much immediately after that, probably early this month. I don't remember how the initial install went (that night was... hazy...), but there were issues with apt-get right from the beginning, regardless of whether I was using the xfce desktop with xorg, running xterm/other applications in a window with xiwi, or if I was just using the chrome developer shell and enter-chroot'ing.

Earlier today, I turned on OS verification, wiping the device, then turned on Developer Mode and did the process of installing Trusty over again (I thought maybe since I had left Developer Mode on when I powerwashed the first time, maybe there was some variable that I wasn't controlling for by leaving it on... I wanted it to be in the same from-the-manufacturer state as when I did my first install, Precise, so that maybe it would work better. Spoilers: it didn't work). The install failed very late, with the same http segmentation fault. It occurred after installing all of the packages associated with the xfce target, and beginning installation of the cli-extra target. Note: I didn't install the cli-extra target when I installed Precise. But I'm not sure that has anything to do with it, since the issue occurs very haphazardly, and this could have been a coincidence. I will get to the description of my failed install from this morning in a bit, but first I will describe the issues I found on my previous Trusty install since I tested it way more.

Just to eliminate confusion… I have had three Ubuntu chroots using crouton:

1. Precise (encrypted, initial targets: xfce; updated with xiwi)
2. Trusty (encrypted, initial targets: audio, cli-extra, extension, keyboard, touch, xfce-desktop, xiwi; updated with xorg) (yeah, I know some of those are redundant, but that’s what I did at the time)
3. Trusty (encrypted, initial targets: cli-extra, keyboard, xfce, xiwi)

Essentially, this is a comprehensive description of the http/https segfault issue I found while I was on install #2, and the steps/variations taken to trigger them:

Chromebook info:

Acer R11, 2GB RAM

Version 53.0.2785.129 (64-bit)
Platform 8530.90.0 (Official Build) stable-channel cyan
ARC Version 3284968
Firmware Google_Cyan.7287.57.82

Description of different steps taken to trigger the issues:

Method A: as controlled a method as possible

1. Fresh restart of the chromebook
2. With no other tabs or apps open, ctrl+alt+t, shell, sudo enter-chroot
3. sudo apt-get update

• This works, and I could run it multiple times in a row (most I tried was four times in a row trying to trigger the issue)

4. sudo apt-get install xxxxx

• Sometimes it would install a package or two in a row without any errors

5. sudo apt-get update/install xxxxx

• Eventually, usually only after the first couple times, this action would fail at some point during the...

Get:1 http://archive.ubuntu.com/ubuntu/ trusty-updates/main somepackage1 amd64 2.9.2-4ubuntu4.14.04.1 [87.4 kB]
Get:2 http://archive.ubuntu.com/ubuntu/ trusty-updates/main somepackage2 amd64 2.3-19ubuntu1.14.04.1 [203 kB]
Get:3 http://archive.ubuntu.com/ubuntu/ trusty-updates/main somepackage3 amd64 2.9.2-4ubuntu4.14.04.1 [25.1 kB]

...phase of the apt-get process. Sometimes, but not often, it would fail immediately after the...

Need to get 12.3 MB of archives.
After this operation, 456 MB of additional disk space will be used.

...phase of the apt-get process. Either way, it would throw this message:

E: Method http has died unexpectedly!
E: Sub-process http received a segmentation fault.

Or, it would throw the same message, but “https”.

Method B: second-most controlled method

1. Fresh restart of the Chromebook
2. With no other tabs or apps open, ctrl+alt+t, shell, sudo startxfce4
3. Now at the xfce4 desktop, open a terminal, sudo apt-get update

• Same behavior as trackpad configuration (not a bug) #3 in Method A

4. sudo apt-get install xxxxx

• Same behavior as "Failed to retrieve InRelease" error #4 in Method A

5. sudo apt-get update/install xxxxx

• Same behavior as How do I prevent my Acer C7 from sleeping when lid is closed? #5 in Method A
• Sometimes, if I did it enough, especially if other things were open, I would start observing other failures (icons disappeared from desktop, window actions would not work, toolbar/whisker menu would not work, applications would not start, alt+f2 (forward button) would not open run dialog/appfinder, etc.). But I don’t have a detailed description of exactly when that would happen or what exactly would happen, because I didn’t really write much down.

Method C: using a bunch of memory in the chroot

1. Fresh restart of the Chromebook
2. With no other tabs or apps open, ctrl+alt+t, shell, sudo startxfce4
3. Now at the xfce4 desktop, open firefox, open maybe seven or eight sites in tabs, open Sublime Text 3, then open a terminal, sudo apt-get update

• Immediate failure as described in How do I prevent my Acer C7 from sleeping when lid is closed? #5 of Method A

Method D: using a bunch of memory in ChromeOS

1. Fresh restart of the Chromebook
2. Open five or so tabs in Chrome, then ctrl+alt+t, shell, sudo startxfce4
3. Now at the xfce4 desktop, open a terminal, sudo apt-get update

• Immediate failure as described in How do I prevent my Acer C7 from sleeping when lid is closed? #5 of Method A
• Same thing happens using xiwi
• Eventually the whole thing would crash, likely memory issues
• the XFCE Task Manager (and top, for that matter) never said much was in swap, but memory usage would get very very high before it would happen, and swap was still pretty unused (crosh says I have a little under 3 gigs allocated to zram... tried increasing this with swap enable 4000, which did indeed increase the swap but didn't help. I don't really know how swap with zram works, since it's not actually on the SSD, it's still on RAM but compressed, but hey.)

Method E: normal use

1. Use the Chromebook for a while, opening tabs and using Chrome apps
2. Close all tabs in Chrome, close all other apps, then ctrl+alt+t, shell, sudo startxfce4
3. Now at the xfce4 desktop, open a terminal, sudo apt-get update

• Immediate failure as described in How do I prevent my Acer C7 from sleeping when lid is closed? #5 of Method A
• Same thing happens using xiwi
• Generally didn’t do this as it was easier to just close Chrome and re-open it to get better reliability from the chroot

General observations and fix attempts:

• The http segfault while apt-get was fetching packages from the software sources (that’s what it’s doing during the “Get:1 http://archive…” portion, right?) seemed to occur in times of high memory usage. It seemed to be perfectly fine for a bit in times of low memory usage, but then would start dying, and would never succeed again after it had died once.
• I could exit the chroot and re-enter, and apt-get update would sometimes work the first time, but usually not.
• I could exit the chroot, close Chrome, then re-open it and enter the chroot and it would usually be able to fire off an apt-get update and have it work the first couple times. Roughly the same behavior as a fresh restart of the Chromebook.
• If I checked the running processes at the time of entering the chroot, apt-check was using up 100% CPU and very high memory for a solid 5-10 seconds. I can’t recall exactly, so take this with a grain of salt because I don’t want to add an accidentally false observation, but if I remember correctly, as soon as I saw that, I tried running an apt-get update to see what the Task Manager showed for CPU and memory usage and there was a similarly huge spike. And, I’m pretty sure that would have been the first thing I tried after seeing that for the first time, so I’m pretty sure my memory isn’t faulty on that one. I wish I hadn’t wiped my machine a few hours ago.
• The multiple associations with high memory use and my vague understanding that segmentation faults occur when something writes to somewhere it shouldn’t led me to believe there was an issue with memory management somewhere in apt, so my googling led me to other people with similar issues with http segfaults during apt-get usage. A few of those were fixed by editing one of the apt config files, at /etc/apt/apt.conf.d/70debconf, and raising the apt cache limit by adding a line that reads:
  APT::Cache-Limit “100000000”
  ...or “200000000” (tried both). That didn’t solve anything, even after restarts. I believe I made some other edits to the apt config files, but none of them did anything to help, so I reverted them after each individual change did not pan out. I do believe I left the Cache-Limit in place for a few weeks with no change.
• Tried apt-get clean, apt-get autoremove, no change.

So, that’s pretty much it, I think, at least for install #2.

Now for my Trusty install from this morning, or install #3:

1. Returned to OS-verification mode. Powerwash ensued. Switched back to Developer Mode. Powerwash ensued. Logged in.
2. Installed crouton chrome extension
3. Downloaded latest crouton from usual link
4. Began installation of a Trusty chroot with the following command:
   sudo sh crouton -e -r trusty -t xfce,xiwi,cli-extra,keyboard

• Installed target core with no errors
• Installed target audio with no errors
• Installed target extension with no errors
• Installed target xiwi with no errors
• Installed target gtk-extra with no errors
• Installed target xfce with no errors
• Began installing target cli-extra and hit the error right before fetching the packages. That portion of the installation went as follows:

Installing target cli-extra...
Reading package lists... Done
Building dependency tree       
Reading state information... Done
kbd is already the newest version.
dbus is already the newest version.
The following packages were automatically installed and are no longer required:
  libasound2-dev:i386 libboost-system1.54.0 libc6-dev:i386 libdrm-amdgpu1
  libdrm-dev libmirclient-dev libmirclient7 libmirclientplatform-mesa
  libmirprotobuf-dev libmirprotobuf0 libpciaccess-dev libpixman-1-dev
  libprotobuf-dev libprotobuf-lite8 libprotobuf8 libspeex-dev:i386
  libspeex1:i386 libspeexdsp-dev:i386 libxdamage-dev libxkbfile-dev
  libxtst-dev linux-libc-dev:i386 mesa-common-dev mircommon-dev
  x11proto-damage-dev x11proto-dri2-dev x11proto-dri3-dev x11proto-fonts-dev
  x11proto-gl-dev x11proto-present-dev x11proto-randr-dev x11proto-record-dev
  x11proto-render-dev x11proto-resource-dev x11proto-scrnsaver-dev
  x11proto-video-dev x11proto-xf86bigfont-dev x11proto-xf86dga-dev
  x11proto-xf86dri-dev x11proto-xinerama-dev xserver-xorg-dev zlib1g-dev
Use 'apt-get autoremove' to remove them.
The following extra packages will be installed:
  libedit2
Suggested packages:
  ssh-askpass libpam-ssh keychain monkeysphere
The following NEW packages will be installed:
  libedit2 openssh-client
0 upgraded, 2 newly installed, 0 to remove and 0 not upgraded.
Need to get 651 kB of archives.
After this operation, 3764 kB of additional disk space will be used.
E: Method http has died unexpectedly!
E: Sub-process http received a segmentation fault.
Failed to complete chroot setup.
Unmounting /mnt/stateful_partition/crouton/chroots/trusty...

...and that’s where I’m at now. You can view the whole installation output here: https://gist.github.com/kjleitz/b140b5845a589f3c3684510b9fb879a6

There are some lines which read:

invoke-rc.d: policy-rc.d denied execution of start.

...or stop, or reload, etc. But I believe that’s just to prevent applications from starting after installation, and I’m pretty sure it’s normal, rather than an error. Maybe it’s not? But I don’t really know enough about the installation process or that policy script to say.

Anyway, I think this is happening to quite a few people, and I’m sure their experiences are similar to mine, especially since I keep seeing the Acer R11 Chromebook mentioned. The issue does not seem to actually go away when you downgrade or reinstall apt (as evidenced by #2688 (comment) ) or by making a new chroot/updating the chroot (as in #2688 (comment) ) and it seems to be the same issue as in some other reports/threads (like: #2778 and possibly #2570 although I haven’t actually tried that solution, I only just found it).

SO ANYWAY.

Sorry for the enormous wall of text. But that’s my experience. It doesn’t look like anyone has made any headway here and it’s a real pain in the ass, having to restart the chromebook so often, and sometimes (not often, luckily) losing data when it all comes crashing down. Wish I could do something about it, but it’s not exactly my area of expertise, I wouldn’t know the first place to look, or the first thing to do, even if I knew what the issue was.

Hope this is helpful.

[kjleitz]

Update:

Restarted to start with a clean slate, ctrl+alt+t, shell, sudo enter-chroot.

Told me the chroot hadn't been completed, yada yada. Pressed Y to finish the install. Worked fine. You can read the install output here: https://gist.github.com/kjleitz/0002492e2df21f30fc9561aabd5631a6

ran sudo apt-get update a whole bunch, installed some things, never triggered the error until I purposely got memory usage up to ~70% and ran apt-get update, but then it failed and continued to fail no matter how much I closed. But apart from that, everything was okay, I was able to restart and install things, and it behaved much better. Until I restarted again, opened crosh in a window (have it pinned to the shelf and set to open in a new window, never did that before this moment), entered the chroot, and immediately did the following:

(trusty)kjleitz@localhost:~$ vim 
-su: vim: command not found
(trusty)kjleitz@localhost:~$ sudo apt-get install vim
[sudo] password for kjleitz: 
Reading package lists... Done
Building dependency tree       
Reading state information... Done
The following extra packages will be installed:
  libgpm2 libpython2.7 vim-runtime
Suggested packages:
  gpm ctags vim-doc vim-scripts
The following NEW packages will be installed:
  libgpm2 libpython2.7 vim vim-runtime
0 upgraded, 4 newly installed, 0 to remove and 0 not upgraded.
Need to get 6899 kB of archives.
After this operation, 31.7 MB of additional disk space will be used.
Do you want to continue? [Y/n] y
E: Method http has died unexpectedly!
E: Sub-process http received signal 4.
(trusty)kjleitz@localhost:~$ sudo apt-get update     
E: Method http has died unexpectedly!
E: Sub-process http received signal 4.

Not sure what this new error is, or whether it means the same thing.

[pjchamberlain]

I'm on the beta channel on an R11 with 4MB RAM (it's a German model, I couldn't find a 4MB model in the UK) with trusty.

The issue comes and goes. I can't figure out a pattern. If I restart it disappears. Sometimes it disappears for some time, but then annoyingly reappears seemingly at random.

I don't remember ever seeing this issue before google play and android apps appeared.

[kjleitz]

Did you have an error-free trusty install before google play and android apps were available on the beta channel? Because, while it may very well have something to do with it, I wouldn't want to conflate the two by coincidence. We'd need to see a working trusty install before the play store was made available and an error-prone install afterward, to make that case.

[kjleitz]

Hm. So, in the last failure I posted, #2688 (comment), I received this error:

E: Method http has died unexpectedly!
E: Sub-process http received signal 4.

instead of the usual

E: Method http has died unexpectedly!
E: Sub-process http received a segmentation fault.

A signal 4, if you run kill -l in your terminal, refers to a SIGILL being sent to a process to terminate it. SIGILL is a signal that means the process performed an "illegal instruction," as you can see if you read man signal. It seems that, most often, this signal is triggered when a process attempts to perform an operation that is specific to a processor architecture different from/not supported by your machine's processor.

Another possibility could be that pieces of the executable code are being overwritten in memory with some other mess of data, or that a function pointer in the program points to similar unintelligible data.

Disclaimer: I literally know next to nothing about this stuff, and I mostly just read about it for a couple hours this morning, so I might be totally wrong.

If the first case is true, and the sub-process http is attempting a processor-specific optimization that is not supported by the processor in the R11, I guess the solution would be to manually compile apt-get (?) on your own machine.

If the second case is true, and since there's a decent amount of evidence it's related to memory usage, maybe some RAM is being overwritten when http still needs to access it? Does that make sense? Or maybe some area of memory is being overwritten or altered or compressed that the http process wants to access? The swap functionality on Chromebooks, being enabled by default, does not write to a swap partition on the SSD. Instead, it uses zram, which writes to compressed block device in RAM, which takes up less memory overall (?) than the normal paging in virtual memory.

So maybe at high memory usage, zram unknowingly swaps some memory at addresses that the http sub-process still needs to access, making it read what seems like garbage data instead, and triggering either an illegal instruction signal (if it thinks the bytes it reads signify an incompatible instruction) or a segmentation fault (because it's accessing/pointing to memory that it's not allowed to access). Maybe disabling swap on the machine will help?

I will try, at some point, to disable swap and see if that helps, and also try recompiling the apt-get binaries (not sure how to do this, but I'm sure I can figure that out) to see if that will work.

Again, disclaimer, I don't know if what I'm saying makes sense. I'm a chemist, not a computer scientist. I'm sure as hell not a C programmer, and the extent of my knowledge on operating systems reaches only to the Wikipedia pages, Stack Overflow questions, and various forums that I come across when following a Wild Google Chase.

Does anyone have a better understanding of this?

[pjchamberlain]

@kjleitz I did have an error free trusty install before google play appeared. When google play appeared the main issue I had was with google play and any android apps stopping repeatedly whenever I entered the chroot. That issue was resolved.

I can't remember clearly when this issue started appearing, but I didn't see it before google play appeared.

It is intermittent for me - for example I just accepted a chrome update and followed with a crouton update - the crouton update didn't complete, ending with this issue in an error message.

Recommended packages:
gcc:i386 c-compiler:i386
The following NEW packages will be installed:
libc6-dev:i386 libspeex-dev:i386 libspeex1:i386 libspeexdsp-dev:i386
linux-libc-dev:i386
0 upgraded, 5 newly installed, 0 to remove and 0 not upgraded.
Need to get 2511 kB of archives.
After this operation, 13.5 MB of additional disk space will be used.
E: Method http has died unexpectedly!
Failed to complete chroot setup.
Unmounting /mnt/stateful_partition/crouton/chroots/trusty...
Sending SIGTERM to processes under /mnt/stateful_partition/crouton/chroots/trusty...
chronos@localhost

I ran the crouton update a second time and it completed without any errors.

[sidamos]

I have an Acer R11 4 GB. For me, this issue appeared first BEFORE Google Play was available. And it only happened with Trusty, not with Precise.

[jamesgraves]

I have an Acer R11 4GB with the N3060 dual-core Celeron. Same issues as being discussed. I've not seemed to have any problems doing the installs for 14.04 or 16.04, it is only when running apt-get install inside the chroot that I've seen the http method die.

[orditeck]

It was driving me crazy, really random issue for me.

@fignuts solution earlier in this issue worked well for me, very happy!

[pjchamberlain]

Can't get past this issue since the latest Chrome update
Version 54.0.2840.51 beta (64-bit)
Platform 8743.57.0 (Official Build) beta-channel cyan
ARC Version 3327608
Firmware Google_Cyan.7287.57.82

Installing target core...
Preparing environment...
Preparing software sources...
E: Method http has died unexpectedly!
E: Sub-process http received a segmentation fault.

[pjchamberlain]

Tried @fignuts workaround above but no difference. Unable to run crouton update at all.

[pjchamberlain]

Strangely I can run sudo apt-get update and upgrade no problem in an xfce terminal window in a crouton session.

But unable to run crouton update

[pjchamberlain]

After a day of failing, crouton update ran without an issue. I really have no idea what this issue is correlated with

[drinkcat]

Can't reproduce locally... apt version 1.0.1ubuntu2.14.

[kjleitz]

@drinkcat Are you using an Acer R11, with a Trusty chroot? Try opening enough tabs (in ChromeOS) to register >75% memory usage while you are logged into your chroot. Then, in your chroot, try running apt-get update and install on a few packages, some number of times, alternating between the two. Unless something weird is happening, that should definitely do the trick. At the very least, it should on the Acer R11 2GB model. It happens with faaaar less here, even on a fresh powerwash.

[cmor3]

I gave up with workarounds. I just rerun the update script over and over again until it completes. This last time it took 5 tries, but it usually takes 3 or 4. It doesn't take that much time and the only annoying thing is that I have to enter the encryption password each time.

[ajcollins95]

I got a similar error (Method http has died unexpectedly) and fixed it by changing the .vscode file in etc/apt/sources.list.d. Originally the link in the file was http://... and I changed it to https://.... I know this isn't quite the issue, but it's similar enough that I thought it might help the discussion.

EDIT: It worked for only one install, after that continued to return the same error :(

[swalter972]

Any news on this bug ? I'm under trusty.

[schniedan]

+1, same problem here with latest Chrome OS and latest ubuntu LTS. That's quite unrewarding. Any progress by anybody?

[pjchamberlain]

It is a very annoying bug. I'm not prepared to use an unencrypted chroot. Only workaround that works temporarily for me is to re-install apt with dpkg each time I want to run crouton update

[sedlund]

I think the bug only exists on chroots that are converted to encrypted after the initial install. I had a fresh install of Debian wiith encryption enabled during install that I had no issues with.

[swalter972]

Nope. Fresh install, directly encrypted.

[sedlund]

Thanks for confirming. I guess it's just Ubuntu then.

[pjchamberlain]

I've only installed Ubuntu but have had the same bug on fresh encrypted installations. Sometimes a fresh install has meant the bug didn't appear for a few days but for me it has always re-appeared.

[friedman101]

This bug is the reason I do not run crouton on my C302. I'd be grateful to anyone who took the time to dive in and understand what is causing this!

[xSeditx]

Just installed Ubuntu-Unity on a Samsung Chromebook and some things worked for a while but I was only able to get one or two things, I did update-upgrade etc and immediately it stopped working with the Signal 4 error. If the problem persist I might just try Power washing the Entire Chromebook and starting from scratch. I just read this whole thread and I guess it is safe to assume no reliable fix has been found yet?

[sedlund]

. If the problem persist I might just try Power washing the Entire Chromebook and starting from scratch. I just read this whole thread and I guess it is safe to assume no reliable fix has been found yet?

Power washing will do nothing for this. You can delete the chroot and reinstall if you want, but the outcome will be the same if you choose Ubuntu - which is unsupported.

If you want/require encryption choose Debian - it's basically the same but is supported and works with encryption. Also, you do not want a 3D desktop like Unity / KDE / Gnome 3 - as they rely on 3D acceleration which doesn't work in a chroot - it will use software 3D which is slow. Use a 2D window manager like XFCE / LXDE.

[azet]

I have the same issue on the latest chrome os with Debian just as with Ubuntu. And the chroots weren't converted. I installed a new second Debian which works for now but this bug has fooled me in the past too often to believe it's just gone, pretty sure this install will also see this bug quite soon.

…

On 27.05.2019, at 05:02, Scott Edlund ***@***.***> wrote: . If the problem persist I might just try Power washing the Entire Chromebook and starting from scratch. I just read this whole thread and I guess it is safe to assume no reliable fix has been found yet? Power washing will do nothing for this. You can delete the chroot and reinstall if you want, but the outcome will be the same if you choose Ubuntu - which is unsupported. If you want/require encryption choose Debian - it's basically the same but is supported and works with encryption. Also, you do not want a 3D desktop like Unity / KDE / Gnome 3 - as they rely on 3D acceleration which doesn't work in a chroot - it will use software 3D which is slow. Use a 2D window manager like XFCE / LXDE. — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[binMonkey]

Hi, I just reinstalled a new chroot using this information that I just found ( I'm an idiot. ): #4026.

I no longer have the segmentation/sig 4 problem when I enter-chroot. I can update and install packages with no problems. But when I actually startxfce4 and enter the DE, nothing works. Ever. It used to work if I kept trying. Now it just quits.

I'm using an Acer 14, CB3-431 with 4GB and 32GB.

Does anyone have any ideas or fixes? Is anyone still checking here?

Thanks,

Rich

[WithoutAnAce]

@sedlund I'm running into this same issue, but I was trying to parse the "unsupported" part of your comment. Is that a "Not supported yet by crouton", "not supported by crouton as a design decision", or "not supported by ubuntu"? Should I put in a PR to update the docs about it?

[sedlund]

@WithoutAnAce Yes - ' Not supported by crouton' I don't know the back story, I assume the main developer was only interested in making the latest Debian work and left the rest to the community to support. The supported releases are listed in the help to the crouton command when you list available releases.

You can check which are supported:

https://github.com/dnschneid/crouton/wiki/Crouton-Command-Cheat-Sheet

• List supported Linux releases (-r): sh ~/Downloads/crouton -r list

For Ubuntu only trusty and xenial are 'supported' - whatever that means. They are over 8 and 4 years old - respectively - compared to all of the latest and current releases supported for Debian.

https://github.com/dnschneid/crouton/blob/174af0ebd89941a6ed6254f453d5f0c4758eae49/installer/ubuntu/releases

[WithoutAnAce]

That makes sense. I'm currently using Xenial, but still running into the issue (for the purposes of more information about this bug)

…

On Fri, Jul 12, 2019 at 2:25 PM Scott Edlund ***@***.***> wrote: @WithoutAnAce <https://github.com/WithoutAnAce> Yes - ' Not supported by crouton' I don't know the back story, I assume the main developer was only interested in making the latest Debian work and left the rest to the community to support. The supported releases are listed in the help to the crouton command when you list available releases. You can check which are supported: https://github.com/dnschneid/crouton/wiki/Crouton-Command-Cheat-Sheet - List supported Linux releases (-r): sh ~/Downloads/crouton -r list For Ubuntu only trusty and xenial are 'supported' - whatever that means. They are over 8 and 4 years old - respectively - compared to all of the latest and current releases supported for Debian. https://github.com/dnschneid/crouton/blob/174af0ebd89941a6ed6254f453d5f0c4758eae49/installer/ubuntu/releases — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#2688?email_source=notifications&email_token=AH3QC2FTP33RZF6SGCN2IEDP7DLDDA5CNFSM4CJX52IKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODZ2VB3I#issuecomment-511004909>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AH3QC2AK4EE4OQHQK2VVQ5TP7DLDDANCNFSM4CJX52IA> .

[binMonkey]

Hi, guys. I deleted my Xenial cheroot and was running Debian Stretch happily for a while. I wanted to install Atom and followed these instructions: https://flight-manual.atom.io/getting-started/sections/installing-atom/#platform-linux

THIS COMMAND is the one that brought that happiness to a screeching and bloody halt:
sudo sh -c 'echo "deb [arch=amd64] https://packagecloud.io/AtomEditor/atom/any/ any main" > /etc/apt/sources.list.d/atom.list'

Something about fooling with sources.list.d screws everything up. I immediately threw a seg fault when updating. I added the repository to my /etc/apt/sources.list and updated just fine ( after logging out of the cheroot and restarting my Chromebook ).

THE PROBLEM HAS SOMETHING TO DO WITH sources.list.d. Does that make any sense?

[BenjiFlaming]

Wanted to share my workaround, along with a minor discovery, in the hope of being helpful. :)

I keep a pristine copy of the http binary in my home directory, and I have a separate directory where I archive corrupted versions. I have a script in my home directory, containing the following:

cp /usr/lib/apt/methods/http ~/broken_http_versions/`date --iso`_http \
&& sudo cp ~/http /usr/lib/apt/methods/http

Whenever I run into the issue, I just run this script, and I have a working system again, along with a copy of the damaged http binary, named according to the current date.

I have now collected 9 such damaged binaries. Today, I was curious to compare them, and I noticed that two of them were identical:

(xenial)benji@localhost:~$ md5sum broken_http_versions/*
a2a4aedef3b5b900e2500b73cec19c06  broken_http_versions/2019-04-05_http
838f482c9beafbe3ef0a6af709ca0de6  broken_http_versions/2019-04-15_http
630a6e894a1fda05779378898ed1a836  broken_http_versions/2019-04-20_http
51fae9e3838373c8675595ed81c7f61a  broken_http_versions/2019-04-22_http
3af5d137e7448ebebbfe08063c85067f  broken_http_versions/2019-05-17_http
e880d64f8e5a3963289a7d1df73f7a8d  broken_http_versions/2019-05-28_http
a2a4aedef3b5b900e2500b73cec19c06  broken_http_versions/2019-06-12_http
be6522ac20b2c6e6949ba2fed72dc0f0  broken_http_versions/2019-09-05_http
2688a4f9a74291c89e67d12554ff7862  broken_http_versions/2019-10-11_http

As you can see, the versions from April 5th and June 12th share the same checksum - which at least demonstrates that the corruption is not entirely random.

If this issue starts bugging me enough, I might start running a watchdog process to continuously (maybe once per minute) compare the current checksum of the system's http binary with the most recent checksum captured, and save the new version with a timestamp if it differs. It'd be interesting to see if there's any discernible pattern as to how and when the file is being modified.

Anyway, hope this may prove helpful or enlightening, and/or be a step toward an eventual resolution. :)

[pjchamberlain]

This is such an annoying bug. Grateful to anyone who looks into it.

My workaround is to keep a clean copy of the apt package and to reinstall it every time I get the issue.

[swalter972]

How do you do this ? Le dim. 27 oct. 2019 à 11:02, pjchamberlain <[email protected]> a écrit :

…

This is such an annoying bug. Grateful to anyone who looks into it. My workaround is to keep a clean copy of the apt package and to reinstall it every time I get the issue. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#2688?email_source=notifications&email_token=AAOIVYDTZAJXMFJQ7VKZWADQQVKKDA5CNFSM4CJX52IKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOECK2VAI#issuecomment-546679425>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAOIVYDVHD6OCI44OETLBHDQQVKKDANCNFSM4CJX52IA> .

[monster1612]

fellow C302 user here, just wanting to chime in with some of my findings.

• I just tried spinning up a fresh bionic chroot with XFCE without encryption, and I didn't encounter that dreaded segfault error at all; it ran through the process nicely.
• so I'm conjecturing that the issue is related to encryption itself and not the OS arch; I tried Debian Bullseye with encryption, and apt died somewhere along the way (segfault), so it's not an Ubuntu-specific problem either.

anyone with a working hypothesis and/or possible solution besides running unencrypted, feel free to chime in.

[pjchamberlain]

It does seem to be related to encryption. I always used encryption. The frustration with this bug has meant I have given up using crouton. I now have an Asus C434 which supports crostini and so far it's met my need for running linux applications.

[DennisLfromGA]

RE: encryption

I always install a new chroot without encryption, set everything up the way I want it and then encrypt it with an update afterwards, e.g. -

• sudo crouton -e -u [-n chrootname]

This seems to work best for me and may just help with this issue too.

Hope this helps,
-DennisLfromGA

[monster1612]

it works for the most part, but post-encryption, I've often run into some kind of snag afterwards while my DE (usually XFCE) is running, where the terminal will refuse to spawn after Ctrl-Alt-T or the terminal icon in the dock is clicked, usually with some kind of error (I forgot specifically what). I have strong reason to believe it's related to segfaulting as well, as logging out of XFCE will produce an abrupt exit error that prevents a completely graceful shutdown of the chroot. I'll usually be running something like Eclipse (although once in a while, I've had firefox up as well). is there a way to get crouton to expose more debug info than the terminal it spawns in usually provides?

[kjleitz]

Sad to see this issue closed, if only due to nostalgia. Five and a half years later, and the bug has never been solved. Unsatisfying, but whatcha gonna do? Thank you, @dnschneid, for this weird and awesome piece of software.