crouton: Method http has died unexpectedly during software installation

advice to remove files in

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

has worked for me.

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

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

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:

1. downloading an OLD apt from: https://packages.ubuntu.com/trusty/amd64/apt/download
2. installing it: sudo dpkg -i apt_1.0.1ubuntu2.17_amd64.deb
3. letting it tell me it was broken
4. download actual apt: https://packages.ubuntu.com/xenial/amd64/apt/download
5. installing: sudo dpkg -i apt_1.2.15ubuntu0.2_amd64.deb
6. 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.

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

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

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.

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.

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

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?

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

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!

Has anyone experienced this issue using internal storage?

I am seeing this on internal storage on Asus C302

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 )

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.

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.

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.

1. 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.
2. use dpkg -i to re-install apt, libcurl3, apt-transport-https and any others (see 1.)
3. run apt-get -f install
4. run apt-get update and apt-get upgrade
5. 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.

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.

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:

1. Power outage broke some file integrity and it is now behaving strange. Systemd complexity is a suspect in this case.
2. 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.

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.

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.