I’ve got an old Asus Eee netbook that I run Debian on, since as much as I love Gentoo, I wouldn’t want to compile anything on that Atom N280 – and I’m too lazy to setup distcc.
Unfortunately, the beast tends to fall victim to chronic MCEs, almost systematically in the course of apt-get operation. Reproducibility is always top-notch: trying to resume the upgrade will trigger another MCE at the exact same stage at which the previous occurred. Top-notch indeed, but quite brutal too.
This often leaves the system a bit wonky: it is halfway through an upgrade – i.e., in an inconsistent state – and keeps crashing if I try to complete the upgrade. Varying degrees of wonkiness can be reached according to the package upgrade that failed: from a minor, non-vital package to, say, an X server package. The system may even be left crippled if the crash occurred while upgrading the kernel image, but this will be the subject of another post (I’ll write about it the next time it happens – hopefully not too soon).
So this is the sorry state the system is in after a crash:
$ apt-get upgrade # says the previous operation borked and I should run dpkg --configure -a $ dpkg --configure -a # sorts of resumes the upgrade but eventually panics in the process
The procedure that I’ve been using to work around this kind of breakage is the following:
$ dpkg -r <crashing package> # remove the culprit $ dpkg --configure -a # configure all remaining packages (hopefully these won't trigger a crash) $ apt-get download <crashing package> $ dpkg -i <crashing package's .deb archive> # download and reinstall the crashing package (it usually installs fine at this point) # (the .deb archive must be downloaded anew as often the cached one is corrupted) # (installing through dpkg prevents apt-get from marking the package as manually installed)
Took me some time (and quite a bunch of MCEs) to figure out the exact sequence, but thanks to this I’m now pretty effective at recovering from those apt-get MCEs.