crouton 🚀 - Method http has died unexpectedly during software installation

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 on 16 Jul 2016

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)

sidamos on 17 Jul 2016

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 on 4 Aug 2016

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

pjchamberlain on 5 Aug 2016

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

AndrewMorsillo on 19 Aug 2016

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.

AndrewMorsillo on 19 Aug 2016

👍2

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.

AndrewMorsillo on 19 Aug 2016

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 on 10 Sep 2016

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 on 10 Sep 2016

Issue has returned again for me after doing a crouton update

pjchamberlain on 14 Sep 2016

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).

RafaelGreenblatt on 21 Sep 2016

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 #3 in Method A

4) sudo apt-get install xxxxx

Same behavior as #4 in Method A

5) sudo apt-get update/install xxxxx

Same behavior as #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 #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 #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 #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 https://github.com/dnschneid/crouton/issues/2688#issuecomment-240944438 ) or by making a new chroot/updating the chroot (as in https://github.com/dnschneid/crouton/issues/2688#issuecomment-246994729 ) and it seems to be the same issue as in some other reports/threads (like: https://github.com/dnschneid/crouton/issues/2778 and possibly https://github.com/dnschneid/crouton/issues/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 on 29 Sep 2016

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.

kjleitz on 30 Sep 2016

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.

pjchamberlain on 30 Sep 2016

😕1

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 on 30 Sep 2016

Hm. So, in the last failure I posted, https://github.com/dnschneid/crouton/issues/2688#issuecomment-250607576, 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?

kjleitz on 30 Sep 2016

@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.

pjchamberlain on 1 Oct 2016

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.

sidamos on 1 Oct 2016

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.

jamesgraves on 4 Oct 2016

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

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

orditeck on 6 Oct 2016

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 on 7 Oct 2016

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

pjchamberlain on 7 Oct 2016

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 on 7 Oct 2016

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

pjchamberlain on 8 Oct 2016

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

drinkcat on 11 Oct 2016

@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.

kjleitz on 11 Oct 2016

Oh, interesting. Can you try to look at dmesg when this happens? Maybe some low-memory killer is kicking in.

drinkcat on 14 Oct 2016

Yeah, sure! This is after rebooting the Chromebook, immediately opening crosh in its own tab, entering the chroot, and running sudo apt-get update:

(trusty)kjleitz@localhost:~$ sudo apt-get update
[sudo] password for kjleitz: 
E: Method https has died unexpectedly!
E: Sub-process https received a segmentation fault.

Ran dmesg right after, and here's the output: https://gist.github.com/kjleitz/e890fe0603bab2afdba780ef6a78c9de

kjleitz on 14 Oct 2016

Hey, I've been having this issue recently on my lenovo 13 chromebook. It has 8GB of ram and is rarely maxed out so it may be more of an allocation issue and less of a mem full issue.

here's the /v/l/m from the host:

https://gist.github.com/the-pete/b96a9caf6607e98cd3793be2d1706baf

and output of free, croutonversion, and sudo strace apt-get install supertuxracer:

https://gist.github.com/the-pete/57dd7c76d20b5080fda7770d8d6eb39f

I'm going to dig into this a bit when I get a chance bit it won't be today. Let me know if I can provide more data.

the-pete on 16 Oct 2016

Looking at the following line from my dmesg that I posted in a gist:
[ 136.036241] traps: https[13253] general protection ip:7fe262d8eab0 sp:7ffcfbc118b8 error:0 in libcurl-gnutls.so.4.3.0[7fe262d66000+5f000]

Maybe this has something to do with it? https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=740950

See the following:

I often get random segmentation faults in libcurl-gnutls.so.4, but only
if

    "speed-limit-down-enabled": true

in the configuration file. (Could not reproduce with speed limiting set
to false).

I'll try seeing if I can reproduce this fix later.

kjleitz on 20 Oct 2016

Update chroot, worked for me :)

Joeyob32 on 12 Nov 2016

@Joeyob32 it's when trying to update chroot that I get the error?

pjchamberlain on 13 Nov 2016

I see, can I ask which command you were using to update the chroot? FYI I was running on a chromebook using crouton...

Joeyob32 on 13 Nov 2016

Most recently it was
chronos@localhost / $ sudo sh ~/Downloads/crouton -u -e -r trusty -t xfce,touch,xiwi
but I also see the same error in a chroot environment or within a terminal in an xfce session with
sudo apt-get upgrade

From time to time the issue disappears, seemingly at random, at least I can't find a reliable workaround.

pjchamberlain on 13 Nov 2016

Try sudo sh ~/Downloads/crouton -u -n chrootname on its own, with no other dependencies, just the core release, see it loads. (Running from crosh, yeah?)

Joeyob32 on 13 Nov 2016

@Joeyob32 unless something has changed in the past month, I'm not sure what good that'll do. The issue happens intermittently, and people have frequently suggested that they've fixed it by updating or powerwashing, only to realize that it just went away temporarily and it's still an issue. Read back in the thread for more info if you're interested (if you haven't already)

kjleitz on 13 Nov 2016

It really is a very intermittent issue for me - after trying everything I can think of, I've come to the conclusion is that what works best is to keep trying to run updates over and over until it works.

pjchamberlain on 3 Dec 2016

Unable to install trusty. This is my first time using crouton, so perhaps I am missing something more obvious to experienced croutoners. Wanted to include my details to add to the knowledge of the problem, that it is happening with the most recent beta channel as of the time of this posting.

sudo sh ~/Downloads/crouton -e -r trusty -t xfce,touch,extension
...
E: Method http has died unexpectedly!
E: Sub-process http received signal 4.

Regarding Memory Greater than 75% claim
Restarted Opened Chrome with no other tabs

crosh> shell
chronos@localhost / $ sudo enter-chroot
Password:
Enter encryption passphrase for trusty:
Entering /mnt/stateful_partition/crouton/chroots/trusty...
UID 1000 not found in trusty
Unmounting /mnt/stateful_partition/crouton/chroots/trusty...
chronos@localhost / $

Restarted

sudo sh -e ~/Downloads/crouton -u -n trusty

Worked for installing Trusty
However, still getting errors being reported for apt-get install

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

I am using

Acer R11 2gb ram
Version 55.0.2883.87 beta (64-bit)
Platform 8872.70.0 (Official Build) beta-channel cyan
ARC Version 3554338
Firmware Google_Cyan.7287.57.92

cascadianw on 12 Dec 2016

Same with Acer Chromebook 14. Strangely this only occurred with the intel graphics drivers repository (https), and it gave me a "method died, https" variant of this error. I'm also getting crashes in chrome within the chroot with similar errors in dmesg SELinux / traps / protection errors

idpnd on 23 Dec 2016

I'm getting the same issue with a Lenovo Thinkpad 13 chromebook, so it looks like it's not just an Acer issue. using crouton -u as mentioned earlier in the thread didnt do anything at first, but I tried running it again and it seemed to fix it for now.

SneakyBastardSword on 7 Feb 2017

I have this same problem. I'm using an acer chromebook 14 with ubuntu xenial. It happened before and I updated which fixed it. Now the the problem is back and updating and restarting is not working.

DavidMcLaughlin29 on 12 Apr 2017

I have this problem as well on an Asus C302CA running trusty. But I did find a workaround (at least for the program I was trying to install): Instead of attempting the install from the GUI, I used enter-chroot and ran the install from there. That worked for me.

medicalcodesolutions on 20 Apr 2017

I also had this problem. Mentioned elsewhere, I tried re-installing apt from ubuntu sources. In my case, this solved the issue, at least temporarily.

silasmartinez on 7 May 2017

How do you do that? Dpkg?

Sent from my iPhone

On May 6, 2017, at 10:42 PM, Silas Martinez notifications@github.com wrote:

I also had this problem. Mentioned elsewhere, I tried re-installing apt from ubuntu sources. In my case, this solved the issue, at least temporarily.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.

DavidMcLaughlin29 on 7 May 2017

Yes - I downloaded the .deb appropriate for my install, and simply dpkg -i (apt for my architecture).deb .. I don't know if it will be a persistent fix, but I'm no longer getting http exceptions, so I'll take it for today.

silasmartinez on 7 May 2017

it will be interesting to see if this fixes it permanently - I think it's been suggested before in this thread

pjchamberlain on 7 May 2017

Ok. Thanks.

Sent from my iPhone

On May 7, 2017, at 3:21 AM, pjchamberlain notifications@github.com wrote:

it will be interesting to see if this fixes it permanently - I think it's been suggested before in this thread

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.

DavidMcLaughlin29 on 7 May 2017

I don't believe this is a long term fix. I installed software center, and
the next thing I tried to install threw this exception. With that said,
reapplying the .deb with dpkg got me right back in business. Without much
digging, it does seem like a memory error. Next time this comes up I'll
gather better diagnostics.

On Sun, May 7, 2017, 11:04 AM David notifications@github.com wrote:

Ok. Thanks.

Sent from my iPhone

On May 7, 2017, at 3:21 AM, pjchamberlain notifications@github.com
wrote:

it will be interesting to see if this fixes it permanently - I think
it's been suggested before in this thread

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/dnschneid/crouton/issues/2688#issuecomment-299719691,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AJyEnO1KyteID7sfRDfqpC3HhYNIRUNJks5r3fmkgaJpZM4JN-6Q
.

silasmartinez on 7 May 2017

I was receiving the seg fault with trusty on an R11. Then I closed an Android app as well as the Play Store, ran sudo apt-get install ..., and everything worked as expected.

Perhaps it was an available RAM issue.

Previously, I was seeing:

Need to get 3,101 kB of archives.
After this operation, 10.4 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 a segmentation fault.

qcu on 29 May 2017

I am experiencing the same problems whenever I try to run apt-get update and it happens regardless whether I logout, reboot or reduce RAM in use. However, I have noticed that when I install package repositories using curl with a piped process that initiates apt-get update, it appears to retrieve the updated information correctly.

For example, this actually works:
curl -sL https://deb.nodesource.com/setup_8.x | sudo -E bash -

I also noticed a thread on Reddit which indicates that this problem does not exist for restored chroots which were created over a year ago.

This problem seems like it's a bug which has occurred due to either an update in apt-get and/or crouton in how memory blocks are handled. Unfortunately, C is above my pay-grade.

System specs:
Acer Chromebook 14
Intel(R) Celeron(R) CPU N3160 @ 1.60GHz
Chrome OS Version 58.0.3029.140 (64-bit)
4GB RAM
Ubuntu Unity Xenial

rj919 on 7 Jun 2017

Apt seems to use either libc or klibc when updating and one of these packages has been compiled for Ubuntu with a bug when run on intel chip architecture. However, I was able to effect a workaround by upgrading apt first since it called the other library (the one without the bug) to upgrade. So, the following sequence worked:
ubuntu software center:
install dietlibc-dev
then:

sudo apt-get upgrade
sudo apt autoremove
sudo apt-get update

However I was unable to get this process to work again once it completed.

The problem seems to originate in the latest package of libc-bin and/or libklibc compiled for Ubuntu and how it handles intel processes. Unfortunately, downgrading apt in order to return to a prior working library is likely to have many unintended consequences. So, the real solution seems to be in fixing how libc-bin and/or libklibc is compiled.

rj919 on 18 Jun 2017

Acer R11, 4 GB, Chrome stable channel, Ubuntu trusty.
After a fresh boot, I always get the HTTP error for apt-get. I think, it happens that often since activating the Android runtime, but could be coincidence.
When I manually reinstall apt from https://packages.ubuntu.com/trusty/amd64/apt/download, then apt-get works 1-2 times, before it fails again.
Then I manually install apt again and so on... This behavior seems very strange to me...

sidamos on 23 Jun 2017

My attempts to fix this problem came to no avail. So, I decided to install kali on my Chromebook instead. So far, there seems to be no problem running updates on the kali-rolling distro. On top of that, the instabilities I was encountering while running chromium have also gone away.
At this point, my only guess is that the problem lies with the libc library that is compiled for Ubuntu. Since the problem temporary goes away when an alternative version of libc is installed. But, that is only a guess.

rj919 on 23 Jun 2017

I had the same issue, only with httpS, not http. I managed to solve it by removing one of the sources files in /etc/apt/sources.list.d/

Could you try that? Or perhaps post the contents of /etc/apt/sources.list and /etc/apt/sources.list.d/* ?

mverwijs on 15 Jul 2017

Same issue for me when I run 'sudo apt update'. I get the Method https error, and either Segfault, or Signal 4 or Signal 5 error. I'm trying on an ASUS c302 4gb RAM, with both Ubuntu Xenial and Debian Stretch.

awgm on 11 Aug 2017

It seems that the number of packages being installed has something to do with triggering the problem.

After accumulating a long list of packages to be updated, I had tried running sudo aptitude full-upgrade which then failed with the usual https died error.

Just for yucks, I tried to individually install some of the packages and I was surprised to see that work.

Trying to install more than a dozen at once still triggered the problem, but installing just a few at a time seemed to be OK. And with less than eight or so packages left, I was able to run the full-upgrade and have it succeed.

So that was inconvenient, but I do finally have an fully updated Ubuntu Xenial chroot again.

jamesgraves on 13 Aug 2017

advice to remove files in

/etc/apt/sources.list.d/*

has worked for me.

Kulak on 15 Aug 2017

👍3

Removing files in/etc/apt/sources.list.d/ is going to remove additional repositories, Opera and Dropbox in my case. That's not good for me. Besides the issue is intermittent for me.

pjchamberlain on 15 Aug 2017

👍1

Yes, I am not on crouton, not on Chrome Book and /etc/apt/sources.list.d/ resolved my issue.

So, it is not Crouton specific...

I am quite concerned as to what could have caused the issue. I noticed it after power outage on my Raspberry PI 3 running standard raspbian.

Unfortunately I run into a bucket of issues. sshd failed to start with segmentation fault and it was at the top of my list. Removing and installing sshd did not help. There were no additional error messages. Just a segmentation fault. Nginx httpd seems to have failed to start as well, but at that moment it was after sshd on my list. According to logs tt-rss application was failing to start as well, but it was of lowest priority.

Eventually I decided to update OS and that's when I run into this issues at apt-get level.

I run into problem running:

apt-get update

I fixed it somehow and then I run into issue running

apt-get upgrade

Given a cascade of issues I have started to doubt the health of the file system, but I had no fsck issues.

So, at the moment I have 2 theories:

Power outage broke some file integrity and it is now behaving strange. Systemd complexity is a suspect in this case.
Because this PI is exposed to internet it might'v been put into odd state by an attack on port 80, 443 or 22.

Both suspects are scary.

I had no issues until now maintaining headless raspberry PI and I have a 2nd one that has shown no issues.

Short Update

I have restored root file system from known good tar backup and have no issues. I have hardened sshd.

Kulak on 15 Aug 2017

👎1

Might be speaking to soon but replacing all instances of https with http in my apt sources seems to have made the issue disappear.

pjchamberlain on 16 Aug 2017

Unable to reproduce the issue for the past 24 hours since I removed all instances of https with http in my apt sources.

Secondary issue for me was that the URL was malformed in the opera-stable.list which caused the following error (after removing the S in https)
E: The method driver /usr/lib/apt/methods/http could not be found
until I corrected it by replacing
http//: with http://

pjchamberlain on 17 Aug 2017

I spoke too soon, like everything else I tried earlier in this thread - issue is still there intermittently

pjchamberlain on 18 Aug 2017

In my case I had to edit the sources.list file to remove an entry that included https.

BrainBacon on 22 Oct 2017

Is it just me or has this issue disappeared? The only thing I've changed is to upgrade trusty to xenial.

pjchamberlain on 22 Nov 2017

It's just you. I'm on trusty and still get this error. I'm glad it went
away for you.

On Nov 22, 2017 1:51 PM, "pjchamberlain" notifications@github.com wrote:

Is it just me or has this issue disappeared? The only thing I've changed
is to upgrade trusty to xenial.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/dnschneid/crouton/issues/2688#issuecomment-346456523,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AJimdj2vvs49ADwk2v4CVtE8o99lVxZhks5s5HtTgaJpZM4JN-6Q
.

doogalbear on 22 Nov 2017

Sorry to hear you're stuck with this. I can confirm though that after 10 days of regular updates this issue has disappeared for me since I upgraded from trusty to xenial.

pjchamberlain on 2 Dec 2017

I can confirm that this is still an issue in Xenial. I was having issues recently in a Trusty chroot on my Toshiba Chromebook 2 2015. I deleted the chroot and installed a new Xenial chroot. It appeared as though it solved the problem until today when it reappeared.

ghost on 2 Dec 2017

I'm rebuilding my chroot and I have this issue every single time. I've tried a couple of different versions of Ubuntu and they all fail on the http method. I didn't have this issue from an older crouton build.

I noticed that something is wrong with the http method library:

(artful)root@localhost:/etc/apt# dpkg -V apt
??5?????? /usr/lib/apt/methods/http
(artful)root@localhost:/etc/apt#

So I changed my source method to be curl+http (curl defaults to https and apparently not all mirrors have https enabled) and apt is much happier now.

(artful)root@localhost:/etc/apt# cat /etc/apt/sources.list
deb curl+http://ports.ubuntu.com/ubuntu-ports/ artful main restricted universe multiverse
deb-src curl+http://ports.ubuntu.com/ubuntu-ports/ artful main restricted universe multiverse
deb curl+http://ports.ubuntu.com/ubuntu-ports/ artful-updates main restricted universe multiverse
deb-src curl+http://ports.ubuntu.com/ubuntu-ports/ artful-updates main restricted universe multiverse
deb curl+http://ports.ubuntu.com/ubuntu-ports/ artful-security main restricted universe multiverse
deb-src curl+http://ports.ubuntu.com/ubuntu-ports/ artful-security main restricted universe multiverse
(artful)root@localhost:/etc/apt#

After that I can do 'apt-get install --reinstall apt'. This fixes the messed up http method library and I can switch back to the default http method.

Is something in crouton messing up this file?

redshodan on 3 Dec 2017

And apparently restarting the crouton chroot re-messes up the http method library. After rebooting my laptop and restarting the chroot I had to repeat the switching to curl+http, and reinstall apt,

redshodan on 3 Dec 2017

Hi @redshodan,
Could you be more explicit in the change in behavior you're seeing?

I tried the following:

Installed curl
Made all "http" pieces of the sources.list file match "curl+http"

deb curl+http://archive.ubuntu.com/ubuntu/ xenial main restricted universe multiverse
deb-src curl+http://archive.ubuntu.com/ubuntu/ xenial main restricted universe multiverse
deb curl+http://archive.ubuntu.com/ubuntu/ xenial-updates main restricted universe multiverse
deb-src curl+http://archive.ubuntu.com/ubuntu/ xenial-updates main restricted universe multiverse
deb curl+http://archive.ubuntu.com/ubuntu/ xenial-security main restricted universe multiverse
deb-src curl+http://archive.ubuntu.com/ubuntu/ xenial-security main restricted universe multiverse

reinstalled apt
tried apt update

It's still very unhappy.
With curl:
E: The method driver /usr/lib/apt/methods/curl+http could not be found.
E: The method driver /usr/lib/apt/methods/curl+http could not be found.
E: Method https has died unexpectedly!
E: Sub-process https received a segmentation fault.

Without curl:
(xenial)@localhost: sudo apt update
Reading package lists... Done
E: Method https has died unexpectedly!
E: Sub-process https received a segmentation fault.
E: Method https has died unexpectedly!
E: Sub-process https received a segmentation fault.

rruenroeng on 18 Dec 2017

@rruenroeng, do you have this soft link:

/usr/lib/methods/curl+http --> /usr/lib/methods/curl

And do you have the package apt-transport-https installed? If not, you will probably need to download it manually and install via dpkg.

redshodan on 18 Dec 2017

@redshodan

Oh baby. This is the first time that "sudo apt-get update" has worked in months. I had to manually install curl using version 7.57.0 downloaded from here, but it worked. I didn't have to do anything with the sources.list file. Installing curl made all the difference.

rruenroeng on 19 Dec 2017

@rruenroeng nice, from there you can reinstall apt and the http method will work. But the next time you run crouton update, it'll trash the http method lib and you'll have to do it all again. I've just left mine as curl+http to avoid all of that.

redshodan on 19 Dec 2017

Glad you got it solved! Could you post a more step-by-step response as well for us semi-newbs?

I was following instructions for manually installing curl here which was going great until I had to install make and of course ran into the Method http has died unexpectedly during software installation error in trying to do so

talker90 on 25 Feb 2018

I thought I had seen the last of this issue - then it reappeared :-( - this time on a new Acer R11 with Version 65.0.3325.89 (Official Build) beta (64-bit) and a fresh install of Xenial with XFCE and then after a couple of months, out of the blue, it's back intermittent and as annoying as ever.

pjchamberlain on 25 Feb 2018

I'm running xenial on a samsung chromebook pro, having this issue as well:

traches@localhost ~  $ sudo apt-get update
[sudo] password for traches: 
Reading package lists... Done
E: Method http has died unexpectedly!
E: Sub-process http received signal 4.

I'm a huge noob, especially with linux. What worked for me, at least temporarily:

Edit: I spoke too soon. Don't do this. It fixed the error message, but broke all my dependencies.

I went here, and downloaded every .deb file for version 1.5.1 and amd64. I dumped them into a folder, cd'ed into it, and ran:

traches@localhost ~/Downloads/apt-install $ sudo dpkg -i *.deb
(Reading database ... 41349 files and directories currently installed.)
Preparing to unpack apt-doc_1.5.1_all.deb ...
Unpacking apt-doc (1.5.1) over (1.5.1) ...
Preparing to unpack apt-transport-https_1.5.1_amd64.deb ...
Unpacking apt-transport-https (1.5.1) over (1.5.1) ...
Preparing to unpack apt-utils_1.5.1_amd64.deb ...
Unpacking apt-utils (1.5.1) over (1.5.1) ...
Preparing to unpack apt_1.5.1_amd64.deb ...
Unpacking apt (1.5.1) over (1.5.1) ...
Preparing to unpack libapt-inst2.0_1.5.1_amd64.deb ...
Unpacking libapt-inst2.0:amd64 (1.5.1) over (1.5.1) ...
Preparing to unpack libapt-pkg-dev_1.5.1_amd64.deb ...
Unpacking libapt-pkg-dev:amd64 (1.5.1) over (1.5.1) ...
Preparing to unpack libapt-pkg-doc_1.5.1_all.deb ...
Unpacking libapt-pkg-doc (1.5.1) over (1.5.1) ...
Preparing to unpack libapt-pkg5.0_1.5.1_amd64.deb ...
Unpacking libapt-pkg5.0:amd64 (1.5.1) over (1.5.1) ...
Setting up apt-doc (1.5.1) ...
dpkg: dependency problems prevent configuration of apt:
 apt depends on libgnutls30 (>= 3.5.6); however:
  Version of libgnutls30:amd64 on system is 3.4.10-4ubuntu1.4.
dpkg: error processing package apt (--install):
 dependency problems - leaving unconfigured
Setting up libapt-pkg-doc (1.5.1) ...
Setting up libapt-pkg5.0:amd64 (1.5.1) ...
dpkg: dependency problems prevent configuration of apt-transport-https:
 apt-transport-https depends on apt (>= 1.5~alpha4~); however:
  Package apt is not configured yet.
dpkg: error processing package apt-transport-https (--install):
 dependency problems - leaving unconfigured
dpkg: dependency problems prevent configuration of apt-utils:
 apt-utils depends on apt (= 1.5.1); however:
  Package apt is not configured yet.

dpkg: error processing package apt-utils (--install):
 dependency problems - leaving unconfigured
Setting up libapt-inst2.0:amd64 (1.5.1) ...
Setting up libapt-pkg-dev:amd64 (1.5.1) ...
Processing triggers for man-db (2.7.5-1) ...
Processing triggers for libc-bin (2.23-0ubuntu10) ...
Errors were encountered while processing:
 apt
 apt-transport-https
 apt-utils

Despite the dependency errors, apt-get seems to work now. Shotgun approach worked out. For now.

traches@localhost ~/Downloads/apt-install $ sudo apt-get update
Hit:1 http://archive.ubuntu.com/ubuntu xenial InRelease
Get:2 http://archive.ubuntu.com/ubuntu xenial-updates InRelease [102 kB]
Get:3 http://archive.ubuntu.com/ubuntu xenial-security InRelease [102 kB]
Get:4 http://archive.ubuntu.com/ubuntu xenial-updates/main Sources [300 kB]
Get:5 http://archive.ubuntu.com/ubuntu xenial-updates/main amd64 Packages [739 kB]
Get:6 http://archive.ubuntu.com/ubuntu xenial-updates/main i386 Packages [685 kB]
Get:7 http://archive.ubuntu.com/ubuntu xenial-updates/main Translation-en [306 kB]
Get:8 http://archive.ubuntu.com/ubuntu xenial-updates/universe i386 Packages [550 kB]
Get:9 http://archive.ubuntu.com/ubuntu xenial-updates/universe amd64 Packages [595 kB]
Get:10 http://archive.ubuntu.com/ubuntu xenial-updates/universe Translation-en [240 kB]
Get:11 http://archive.ubuntu.com/ubuntu xenial-security/main Sources [117 kB]
Get:12 http://archive.ubuntu.com/ubuntu xenial-security/main amd64 Packages [461 kB]
Get:13 http://archive.ubuntu.com/ubuntu xenial-security/main i386 Packages [415 kB]
Get:14 http://archive.ubuntu.com/ubuntu xenial-security/main Translation-en [199 kB]
Get:15 http://archive.ubuntu.com/ubuntu xenial-security/universe i386 Packages [281 kB]
Get:16 http://archive.ubuntu.com/ubuntu xenial-security/universe amd64 Packages [322 kB]
Get:17 http://archive.ubuntu.com/ubuntu xenial-security/universe Translation-en [121 kB]
Fetched 5537 kB in 4s (1264 kB/s)                                 
Reading package lists... Done

Edit: never mind. My shit's all broken.

traches@localhost ~/Downloads/apt-install $ sudo apt-get upgrade
[sudo] password for traches: 
Reading package lists... Done
Building dependency tree       
Reading state information... Done
You might want to run 'apt --fix-broken install' to correct these.
The following packages have unmet dependencies:
 apt : Depends: libgnutls30 (>= 3.5.6) but 3.4.10-4ubuntu1.4 is installed
E: Unmet dependencies. Try 'apt --fix-broken install' with no packages (or specify a solution).
traches@localhost ~/Downloads/apt-install $ sudo apt --fix-broken install
Reading package lists... Done
Building dependency tree       
Reading state information... Done
Correcting dependencies... Done
The following packages will be REMOVED:
  apt apt-transport-https apt-utils ubuntu-minimal unattended-upgrades
WARNING: The following essential packages will be removed.
This should NOT be done unless you know exactly what you are doing!
  apt
0 upgraded, 0 newly installed, 5 to remove and 5 not upgraded.
3 not fully installed or removed.
After this operation, 5135 kB disk space will be freed.
You are about to do something potentially harmful.
To continue type in the phrase 'Yes, do as I say!'
 ?] n
Abort.

rbuchberger on 6 Mar 2018

😄1

I'm on a 2015 Pixelbook with a xenial chroot and have been fighting this issue for quite some time now. I don't have a /usr/lib/methods/curl, and all of my methods are in /usr/lib/apt/methods, but there are none called "curl". I have curl and apt-transport-https installed, but no "curl" in methods to which I can create a symlink.

This is a really frustrating problem. Are there any reliable fixes yet?

orangganjil on 9 Mar 2018

@orangganjil I've figured out an alternate solution:

Download apt-transport-https via the browser, then manually install it:
```
$ sudo dpkg -i ~/Downloads/apt-trans*
```

Edit /etc/apt/sources.list to something like this:

deb https://mirrors.xmission.com/ubuntu/ xenial main restricted universe multiverse
deb-src https://mirrors.xmission.com/ubuntu/ xenial main restricted universe multiverse
deb https://mirrors.xmission.com/ubuntu/ xenial-updates main restricted universe multiverse
deb-src https://mirrors.xmission.com/ubuntu/ xenial-updates main restricted universe multiverse
deb https://mirrors.xmission.com/ubuntu/ xenial-security main restricted universe multiverse
deb-src https://mirrors.xmission.com/ubuntu/ xenial-security main restricted universe multiverse

You don't have to use that particular mirror, but you do currently have to use something other than archive.ubuntu.com, since it is not accepting HTTPS connections at the moment.

I found this mirror via a list of Ubuntu mirrors that responds to HTTPS which someone posted on Reddit a few years ago. It may now contain incorrect information, but the xmission.com one works as of this posting. I've had good luck with that hosting service's reliability in the past with other projects, which is why I chose it.

Profit:
```
$ sudo apt update && sudo apt upgrade
```

You don't need to reinstall apt or anything like that.

As a bonus, you're now fetching your software over HTTPS, so it can't be MITM'd, and you're not burdening Ubuntu's servers. Because of this, I'm leaving my configuration like this rather than revert it.

tangentsoft on 10 Mar 2018

@tangentsoft

Thanks for the response. I tried all of that and got the dreaded:

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

I then removed everything in my /etc/apt/sources.list.d/ directory, attempted it again, and got the same error. I then exited the chroot and did the sudo sh crouton -u -u, which actually worked; however, the crouton update replaced my sources.list file contents.

I then re-entered the chroot and could run sudo apt update just fine, so I added the files back to the sources.list.d directory and, since one of the repositories requires https (Signal Messenger), I now cannot do a sudo apt update again without getting the error:

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

Ugh. It is really tough to tell whether this is a crouton or chroot problem.

orangganjil on 10 Mar 2018

@orangganjil I've just retried the update, and it succeeded, so I put sources.list back to its stock configuration and the problem reappeared! Swapping the configuration back to my xmission based one fixes it again, so as far as I can tell, I have a reliable solution here.

EDIT 1: And now after a reboot and re-entry to the chroot, the symptom is back again! Now no amount of fiddling with sources.list helps. I guess it was nice while it lasted...

EDIT 2: I've just blown away my Ubuntu Xenial chroot and re-created it fresh — not from backups! — and the symptom reappears. I assume from this that the problem is not something broken locally, which I can easily fix myself. Since "signal 4" is "illegal instruction," as pointed out above, I wonder if the chroot is interacting badly with some Chrome OS security thing.

EDIT 3: I've built a new chroot using Debian Stretch, and it appears to have solved the problem. I'll report back if it starts throwing errors again.

tangentsoft on 10 Mar 2018

😕1 👍1

I started experiencing this issue today after having used a Xenial chroot for about 3 weeks. This Stack Overflow answer has fixed my issue, at least for now.

https://unix.stackexchange.com/a/320991

christopher-bimson on 1 Apr 2018

🎉1 👍1

I keep commonly running into this issue, so I'll throw my fix into the mix:

I used to be able to get rid of the apt segfaulting by:
OLD WAY:

sudo cp /etc/apt/sources.list /etc/apt/sources.list.temp
sudo rm /etc/apt/sources.list
sudo touch /etc/apt/sources.list
sudo apt clean

reboot

sudo apt clean
sudo apt update
sudo cp /etc/apt/sources.list.temp /etc/apt/sources.list
sudo apt clean
sudo apt update

HOWEVER: This stop working for me recently ¯\_(ツ)_/¯

WHAT DID WORK:

downloading an OLD apt from:
https://packages.ubuntu.com/trusty/amd64/apt/download
installing it:
sudo dpkg -i apt_1.0.1ubuntu2.17_amd64.deb
letting it tell me it was broken
download actual apt:
https://packages.ubuntu.com/xenial/amd64/apt/download
installing:
sudo dpkg -i apt_1.2.15ubuntu0.2_amd64.deb
running:

sudo apt clean
sudo apt-get -f install
sudo apt update

Installing the old version may be unnecessary and I plan to update this next time this happens to me with the result of attempting without the old install first.

It's so annoying that this issue keeps happening. I would say 1/8 of my apt related activities causes the seg fault for all subsequent apt calls and I have to do some crazy fix.

Update:
Newest working method:

sudo cp /etc/apt/sources.list /etc/apt/sources.list.temp
sudo rm /etc/apt/sources.list
sudo dpkg -i apt_1.2.15ubuntu0.2_amd64.deb

reboot

sudo cp /etc/apt/sources.list /etc/apt/sources.list.temp
sudo apt clean
sudo apt update

UPDATE 2:
after you have a working http/https. following @mrpnelson 's solution below worked BEAUTIFULLY for me. No reboot needed! Though you should modify the script and inital cp to also cp the https proc as well since that one fails randomly in the exact same way http does for me.

paul-kline on 4 Apr 2018

❤1 👍1

I have only installed crouton today on a new samsung 2in1 510. Initally it worked fine, but then I ran into the problem described so well by everyone above, apt-get fails via http not working. The solution I arrived at is not permanent, but assumes that repeated corruption is a "feature" of this kind of setup. I had to do much of this with a non-working apt and relied on hints given by many in the previous postings.

download current version copies of apt, libcurl3, and apt-transport-https deb files. put them in a safe, known location. If there are missing dependencies, get them too. Use a browser for this. Don't delete these, you'll install them several times.
use dpkg -i to re-install apt, libcurl3, apt-transport-https and any others (see 1.)
run apt-get -f install
run apt-get update and apt-get upgrade
do whatever you needed apt-get for. if it fails before you get done, repeat these steps again.

It appears that there is an ongoing corruption happening and it happens in use. Don't expect this to fix it for more than a few moments. From my brief experience it's not necessary to reinstall crouton, restart or reboot. your experience may vary, but so far this is working for me.

edit: I've combined the above steps into a bash script so it only takes one sudo'd command to get back into a good state. So far this has solved the issue on a case by case basis and has the added benefit of keeping the system up to date.

cmor3 on 10 Apr 2018

👍1

Very frustrating - I've tried almost all the fixes on this thread but the issue always comes back. What works best for me is to keep running crouton until it works, usually takes 5 or six times.

pjchamberlain on 10 Apr 2018

A reasonable workaround for me was to enter the chroot, and then create a backup copy of the http method file (/usr/lib/apt/methods/http in xenial) to /usr/local/lib/apt/methods/http-backup. Generally on first entering the chroot it's fine. Test apt (e.g. update) at this point, to ensure the file you copied was good.

With a working reference file, you can then alias a command or write a script to replace the http method as needed. E.g., I made the following script in /usr/local/sbin/fixapt:

#!/bin/bash  
sudo cp /usr/local/lib/apt/methods/http-backup /usr/lib/apt/methods/http

Then, if apt starts failing, sudo fixapt can resolve quickly. As/when that shared object is updated, it's likely you'll need to make periodic updates to your backup copy. At the very least, hopefully this approach helps prevent some more time-intensive workaround approaches.

mrpnelson on 10 Apr 2018

❤1

Recently after switching on encryption with -e for my crouton install, I began to have this issue. Upon doing (in chrome os shell): sudo sh ~/Downloads/crouton -u -n xenial to update, then the issue is resolved.

Not sure if this issue will come back, for the moment, it fixed the issue of http issue.

ipstone on 5 May 2018

I had this issue for a week, and this link helped me figure it out: https://askubuntu.com/questions/104160/method-driver-usr-lib-apt-methods-https-could-not-be-found-update-error.

At the command line, run cd /etc/apt/sources.list.d && cat * | grep https. If that command doesn't return clean, then go change every "https" to "http" in the files under /etc/apt/sources.list.d.

spwg on 12 May 2018

👍1

Ran into this issue again, I restored the default sources.list and that did the trick.

BrainBacon on 18 Jul 2018

The issue is in /etc/apt/sources.list. In my case, docker repo was failing:

(xenial)x@localhost:$ cat /etc/apt/sources.list
deb http://archive.ubuntu.com/ubuntu/ xenial main restricted universe multiverse
deb-src http://archive.ubuntu.com/ubuntu/ xenial main restricted universe multiverse
deb http://archive.ubuntu.com/ubuntu/ xenial-updates main restricted universe multiverse
deb-src http://archive.ubuntu.com/ubuntu/ xenial-updates main restricted universe multiverse
deb http://archive.ubuntu.com/ubuntu/ xenial-security main restricted universe multiverse
deb-src http://archive.ubuntu.com/ubuntu/ xenial-security main restricted universe multiverse
deb [arch=amd64] http://download.docker.com/linux/ubuntu xenial stable
# deb-src [arch=amd64] http://download.docker.com/linux/ubuntu xenial stable

I disabled # deb [arch=amd64] http://download.docker.com/linux/ubuntu xenial stable (the second line from the bottom) and the problem disappeared. So, just check your /etc/apt/sources.list

Zin4uk on 4 Aug 2018

Just installed Crouton on a brand new Chromebook - Asus C302. This issue is still there intermittently. The only work around for me is to keep trying until it works.

pjchamberlain on 5 Sep 2018

It has been consistently failing for me recently. I've been downloading
packages from the Ubuntu package search, and installing them manually with
dpkg.

jamesgraves on 5 Sep 2018

thanks @spwg - the HTTPS needed altered in my sources to fix things and let me update again. Not sure how bad a security risk that is, but maybe others can shed light on issue more. ( xenial on Acer 571 )

battez on 6 Sep 2018

👍1

This issue has been getting worse for me. It's gone from intermittent to all the time. Only a reboot clears it and only for one run of Crouton update.

pjchamberlain on 21 Sep 2018

/usr/lib/apt/methods/http is being changed somehow. if you have the problem you can see it dumping core if you run it from cli.

you can run:

debsums apt

to verify apt package integrity (apt install debsums)

to fix - download your version of the apt deb and reinstall it.

currently i'm attempting to mask the problem by making the http method binary immutable:

sudo chattr +i /usr/lib/apt/methods/http

obviously upgrading apt from now on will fail unless you chattr -i the file until the problem is rectified.

you can mark apt to be on hold for future upgrades

apt-mark hold apt

sedlund on 3 Oct 2018

Yes confirmed - apt fails a debsums check for http

debsums apt 
/usr/lib/apt/methods/http                                                 FAILED

Does the crouton script change or update apt?

pjchamberlain on 4 Oct 2018

Changing the file to be immutable did not work for me after all. After doing an apt update of my system, of libstdc++ and other core system libraries the http binary changed again. I went to reinstall apt and it errored appropriately that I did not have permission (as root) to change the http binary. I removed the immutability flag to reinstall apt, and resolved the issue again. This leads me to believe that the file is changed outside of the chroot.

This chroot is one that I have converted to encrypted after having installed it normally.
Currently I think it has something to do with FUSE and ecryptfs

sedlund on 4 Oct 2018

/usr/lib/apt/methods/http actually corrupt? Weird! Yeah, I see the same corruption issue, and also use encrypted crouton.

Does anyone have a copy of the corrupt binary? I'm curious if the mutation is predictable. Same block corrupted each time, or sections of binary zeroed out.

If you have a corrupt binary, upload it (see [1]) or run this and tell us what you find:

# any flavor you like
diff <(xxd http.evil) <(xxd http.good) | less -R
diff <(xxd http.evil) <(xxd http.good) | colordiff | less -R
diff -y <(xxd http.evil) <(xxd http.good) | colordiff | less -R

(I had a corrupt binary, and copied it to http.bad1, but now it gives same sha hash as good binary.. so either it's a conspiracy or I goofed up and overwrote it.. which is more likely)

[1] Here is good (debsums OK) http bin, version 1.2.27 https://gist.github.com/computercolin/0d231f3e57d0eee9d60b3dc88bffafce
I ran base64 > ~/Downloads/outp and uploaded that to gist.github.com . You could upload to Dropbox, but 3 years from now my gist will still be there for reference, where as you probably delete your file from Dropbox ;]

computercolin on 6 Oct 2018

I've compared two different bad http binaries on my system from the original. Both show changes from e000 to efff in the file (a 4k block) from the original and from each other.

here is one bad binary (1.6.3ubuntu0.1)
https://gist.github.com/sedlund/af7788087f04399643d25a255522a162

sedlund on 6 Oct 2018

Okay, my binaries blew up again and I have copy of corrupt http.
On xenial, http v1.2.27, I am seeing chunk of binary replaced by repeating garbage.
Here is the binary diff: https://gist.github.com/computercolin/ae4a72ac75c455f74ee1abe2e0e17bfe
(seems bytes 3585,3840 were affected)

This repeating garbage pattern
cb97 9d32 372a 1a3c 4b9a 1647 b049 f092
is not found anywhere in original binary.

Yes it is interesting, the corruption occurs in the first 4k bytes (and fs block sizes all appear to be 4k, as well). Now if only I knew what else to make of this ;)

If needed, here is copy of entire good v1.2.27 http binary:
https://gist.github.com/computercolin/0d231f3e57d0eee9d60b3dc88bffafce
and here is (my current) bad v1.2.27 binary:
https://gist.github.com/computercolin/16245fddeb12175404ef4de7ea0a56eb

# http.1.2.27 Good:
# sha256: 786c8b6bc495970c73e7d97167635d226ffc98784a9f3efcd2f0dcab4f93561a
# sha1: d6e4ea0f4127a5ce0b470bce3325e9ab8c12c31e

# http.1.2.27 Bad:
# sha256: a2e4ff0a4e9428fa0811e97ea3b2294343ae0a1d27e8365ba84232046e7f3d00
# sha1: 84ffb2bc96318d899b86062eda2ad38d7588d6bf

computercolin on 11 Oct 2018

Well, binary is already screwed up again.
Diff: https://gist.github.com/computercolin/337cd74606bb8d859eb77554e92b460f
(previous corruption diff: https://gist.github.com/computercolin/ae4a72ac75c455f74ee1abe2e0e17bfe )

Same byte range affected!
corruption1: 3585,3840
corruption2: 3585,3840

I have not rebooted and have not stopped the chroot. I don't know if doing that, or otherwise changing the state of ecryptfs/fuse would impact the behavior (or stop it from happening).

Full copy of http v1.2.27 bad2 (above post, see bad1 binary)
https://gist.github.com/computercolin/0d336a4583ab09f42bc1239e78c18bff

computercolin on 11 Oct 2018

Update 15 hrs later, has fixed itself! The only action I took was to close the lid and let machine go to sleep. Didn't didn't start new cli/xorg/xiwi session, didn't close cli/xorg/xiwi session. Nothing.

Binary now reads with correct sha sum, and apt works once again. So, if it's fuse/ecryptfs, suspend resets something and allows /usr/lib/apt/methods/http to read correctly.

computercolin on 11 Oct 2018

It's a really strange issue. I wonder if @dnschneid has any thoughts on this particular file getting changed?

sedlund on 12 Oct 2018

I had this bug for ages and its been driving me nuts. Today for the first time in ages crouton update worked though. Randomly I found that if I just say $ sudo sh crouton.sh -u -n <chrootname> is fails with the old E: Method http has died unexpectedly! but if I include all the chroot targets in the command $ sudo sh crouton.sh -u -t xiwi,keyboard,e17,extension,touch -n <chrootname> then its OK. I'm samus dev mode with Ubuntu 16.04.5 LTS

9modulus on 13 Oct 2018

It is a very strange issue, sometimes closing the shell tab and opening a new one fixes it for me, but it's only ever temporary, it always comes back.

pjchamberlain on 13 Oct 2018

Side note: I'm kind of impressed this issue is still so active after more than _two years_ with no consistent solution or identifiable root cause

kjleitz on 17 Oct 2018

😕1 👍1

sometimes, like today, waiting 20 minutes and trying again works - in the same tab and shell session.

pjchamberlain on 25 Oct 2018

What I have understood so far as being features of this bug. The problem arises in the following cases:

Acer R11 (amount of RAM does not seem to matter)
Using encryption
Distribution does not seem to matter

Corruption of some file (notably /usr/lib/apt/methods/http) is what gives this error message. However, this corruption does not appear to be permanent, which is wierd! The problem is intermittent and can disappear or reappear unpredictably.

So it would seem that, a file which has already been read and decrypted is being mis-read in memory. This would point to some sort of hardware error either with the TPM or with the memory or with the SD card reader.

I got bitten badly by this error since, after trying all morning to update the chroot and intermittently getting this error, at some point I panicked and aborted a backup. All this was on an external SD card which is now (apparently) permanently unreadable. :-(

kapilhp on 10 Nov 2018

@kapilhp yes to point 2. and 3. but it's not confined to the Acer R11 - I'm getting the same issue on an Asus C302 (I also had it on an Acer R11 in the past)

pjchamberlain on 10 Nov 2018

Yes to point 2, but I'm using the Samsung Chromebook Pro. I am also running the chroot off of an SD card, Perhaps that is part of the issue. Has anyone experienced this issue using internal storage?

BrainBacon on 14 Nov 2018

Has anyone experienced this issue using internal storage?

I am seeing this on internal storage on Asus C302

kpanko on 14 Nov 2018

❤1

Yes, I've only ever installed crouton on internal storage.

pjchamberlain on 14 Nov 2018

Me too. I'm seeing this on an Asus C302 on internal storage with Xenial using encryption.

Manually downloading apt and installing it with dpkg does resolve the issue for me, but only for a single use of apt-get update and upgrade or a single run of crouton update. After that the issue returns.

pjchamberlain on 18 Nov 2018

This issue is the reason I'm running Manjaro (using legacy boot) on my C302 instead of crouton. I keep an eye on this topic with hopes that the issue will be resolved at some point.

From looking at other's comments (and my own experience) it definitely seems related to running an encrypted chroot. Also, this was not always the case. I ran encrypted crouton chroots ~3 years ago without issue on several machines. This regression was either caused by changes to crouton or to ChromeOS

friedman101 on 23 Nov 2018

Because people were referring to the Acer model, I have a Chromebook Pixel (2015), same problem.

azet on 3 Dec 2018

Is this still an issue? Any chance it's related to #3947 ?

friedman101 on 15 Jan 2019

Is this still an issue? Any chance it's related to #3947 ?

this issue exists. not much data in the one you link.

I have a newly encrypted debian chroot that I created encrypted from the start and haven't had issues with it though.

sedlund on 15 Jan 2019

Yes this issue very much still exists for me - I don't know if it's related to encryption, although I do have an encrypted chroot (on an Asus C302). The only workaround I have is to enter-chroot, reinstall the latest apt with dpkg, exit the chroot and then run crouton update, This fix only works for one or two runs of apt then the issue returns

pjchamberlain on 15 Jan 2019

This morning after a ChomeOS update, my workaround of reinstalling the latest apt has stopped working. Any ideas on a workaround?

pjchamberlain on 23 Feb 2019

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.

cmor3 on 25 Feb 2019

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 :(

ajcollins95 on 30 Mar 2019

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

huberte on 19 May 2019

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

schniedan on 23 May 2019

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

pjchamberlain on 23 May 2019

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.

sedlund on 23 May 2019

Nope. Fresh install, directly encrypted.

huberte on 23 May 2019

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

sedlund on 23 May 2019

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.

pjchamberlain on 23 May 2019

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!

friedman101 on 23 May 2019

😄1

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?

xSeditx on 26 May 2019

. 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.

sedlund on 27 May 2019

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 notifications@github.com 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.

azet on 27 May 2019

Hi, I just reinstalled a new chroot using this information that I just found ( I'm an idiot. ): https://github.com/dnschneid/crouton/issues/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

binMonkey on 18 Jun 2019

👎1

@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?

WithoutAnAce on 12 Jul 2019

@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

sedlund on 12 Jul 2019

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 notifications@github.com
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
https://github.com/dnschneid/crouton/issues/2688?email_source=notifications&email_token=AH3QC2FTP33RZF6SGCN2IEDP7DLDDA5CNFSM4CJX52IKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODZ2VB3I#issuecomment-511004909,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AH3QC2AK4EE4OQHQK2VVQ5TP7DLDDANCNFSM4CJX52IA
.

WithoutAnAce on 15 Jul 2019

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?

binMonkey on 8 Aug 2019

👎1

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. :)

BenjiFlaming on 25 Oct 2019

👍2

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.

pjchamberlain on 27 Oct 2019

How do you do this ?

Le dim. 27 oct. 2019 à 11:02, pjchamberlain notifications@github.com 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
https://github.com/dnschneid/crouton/issues/2688?email_source=notifications&email_token=AAOIVYDTZAJXMFJQ7VKZWADQQVKKDA5CNFSM4CJX52IKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOECK2VAI#issuecomment-546679425,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAOIVYDVHD6OCI44OETLBHDQQVKKDANCNFSM4CJX52IA
.

huberte on 3 Nov 2019

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.

monster1612 on 6 Dec 2019

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.

pjchamberlain on 6 Dec 2019

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

DennisLfromGA on 6 Dec 2019

👍1

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?

monster1612 on 9 Dec 2019

Crouton: Method http has died unexpectedly during software installation

Please describe your issue:

If known, describe the steps to reproduce the issue:

Most helpful comment

All 143 comments

Method A: as controlled a method as possible

Method B: second-most controlled method

Method C: using a bunch of memory in the chroot

Method D: using a bunch of memory in ChromeOS

Method E: normal use

Related issues