Forcing dpkg through configuration errors

I have been struggling with disk errors for the past few days in Ubuntu, on the 560e that I brought home exactly a week ago. This is unusual for me, unusual for the drive and (generally speaking, in my experience) unusual for Ubuntu … but opinions will vary on that last point, of course.

These were particularly disappointing though, because they damaged some of dpkg’s configuration files. Attempting to install anything spat out an error like this one. …

E: Internal Error, Could not perform immediate configuration (1) on libattr1

Google told me the package could be different between cases, but the source of the error was usually the same — some part of dpkg’s support files had been damaged. In my case it was probably /var/lib/dpkg/status or one of its brethren. Replacing it with status-old was one option, but that didn’t seem to fix anything.

What did work was forcing the obstinate packages to install in spite of dependency issues, and then recovering the faulted packages with apt-get. In other words:

dpkg -i --force-depends libattr1_1%3a2.4.43-3_i386.deb
apt-get -f -y install

A bit brutish, but it got the job done. Eventually I was able to install enough packages and cover enough dependencies to continue installing … whatever it was I was installing. I had forgotten by this point. šŸ˜‰

I’m hypothesizing here, but I suspect that the errors come about in part because of the hardware arrangement of the 560e. No OS I have put on it yet has been able to shut it down completely. The power button is a sliding switch that presses against a spring, which either activates or kills the machine. My only guess is that for some reason, when the shutdown message appears, the drive still hasn’t properly synced, which is triggering errors. Of course I’m not an expert, so it’s only a guess.

One other small point of editorializing — aptitude has fallen in my favor, in the year or so since I drifted away from it. I used to be rather enamored with the Debian-slash-Ubuntu packaging system and how well it handles the tens of thousands of dependencies and interrelationships so well. But coming back to it after a year or so and having spent most of that time with tools like pacman and yaourt, ports and prt-get, or even tazpkg, aptitude is a sluggish toad. I will curb my sharpest criticism and just say it’s not nearly as wieldy and fast as the others I mentioned, and venerable as it is, it needs a tune-up.

And that’s enough for now. šŸ˜

P.S.: Ordinarily you should put sudo in front of those commands. Unless you’re like me, and you assign a root password and su to do system maintenance. Ooh, I’m going to get in trouble for that one. … :mrgreen:

9 thoughts on “Forcing dpkg through configuration errors

  1. anon

    you’re about to get a flood of APT vrs. any-other-package-management-tool comments to the point that it’ll seem like you just posted flamebait. but, hey, it’s your blog, is it not? šŸ˜›
    ps: APT ftw!!!

    Reply
  2. vajorie

    I wonder if I can initiate the package tool flame via:

    Pacman slows time with time due to, I believe, use of text files (or something, whatever). Here’s a link where a solution / work around is provided: http://nooms.de/articles/pacman.html

    I use it in both my netbook and my laptop (5 years old), but I’m not sure if it would be useful to you (your definition of “old” makes my laptop look brand new šŸ˜› )

    Also, (back on topic) what if your hdd is dying?

    Reply
    1. K.Mandla Post author

      I suppose it’s always possible that the drive is dying. It doesn’t seem likely though. I used that drive in a different machine for weeks up until it was swapped into the 560e, and had no problems. So the stark difference in performance between computers suggests the issue is with the laptop. But one never knows. … šŸ˜

      Reply
    2. LeoSolaris

      Hey, thank you for the simple how-to on that pacman tweak. I intend on trying it out to see if it helps any with powerpill/pacman.

      I wonder if this option is actually faster than keeping the textfiles in a tar, and hacking pacman to untar them every time they are needed, the way the current roadmap has it.

      P.S. When I first read your opening sentence, I managed to read “package flame tool” and wondered for an instant how someone managed to code a program just for initiating package flame wars on the web.

      Reply
  3. steve

    This smells like imminent drive death to me as well. The 12yo Toshy Satellite4200 I use went for 6 weeks after I got it then the hdd just died without warning. Also I might be biased but to me, Ubuntu seems like a really bad kludge of Debian sid & testing. I wouldn’t be surprised if the package management system was broken either…Debian for the win šŸ˜‰

    Reply
  4. Pingback: Debating a machine with few merits « Motho ke motho ka botho

  5. Lee

    Putting sudo, sudo, sudo, in front of commands that could potentially damage your system will not save you.

    When I do sysadmin tasks I either log in as root, or I use sudo -i to become root. I’m not about to prepend ‘sudo’ in front of everything I do. That is just plain retarded.

    I’ve been using computers since I was 8 years old. Back when I first started using standard PC’s, DOS 3.3 was pretty much it. You learned pretty quickly not to del *.* files you wanted to keep. You learned pretty fast that format c: had dire consequences. You learned not to blow your foot off. You learned to treat lightly and with care. So when I see sudo, sudo, sudo everywhere I look I kind of shake my head since this practice is about as effective at preventing footbullets as “duck and cover” was at protecting children from nuclear explosions.

    Competence is the only thing that will save you from screwing up your system.

    Reply

Leave a reply to Lee Cancel reply