E: Internal Error, Could not perform immediate configuration (2) on libstdc++6 This caught me out with empdebuild tonight and I want to document how to fix similar problems. (I haven't found the root cause, unfortunately.) 1. This only happens *after* apt-get dist-upgrade has downloaded all the necessary packages within the chroot. 2. emdebian-tools <= 0.7.4 does not handle this error particularly gracefully and the current empdebuild script actually gets in the way a bit because it tries to do too much in the --login command. This has been fixed, due to be committed to SVN tonight and 0.7.4 (or 0.8.0 depending on other issues) will be released soon (as always). Even in >>0.7.4, this bug could still occur (it will just be handled slightly better) and the following method will be needed. A workaround for (<< 0.7.4) is to comment out the call to emsetup in the empdebuild login routine. This allows you to login (use --save-after-login to fix the chroot for next time). 3. This is a bug generated by apt but which (AFAICT) is actually in gcc-4.2_4.2.2-5 and might not appear in subsequent releases. It is also a bug that is "special" to Emdebian chroots because it appears that the 4.2.2-5 update has generated a circular dependency within the set of packages that are installed by default in an Emdebian chroot - a much larger package set than in a normal pbuilder chroot. The problem appears to require some level of Pre-Depends and Essential conflict and it is the combination of a failed Pre-Depends in a circular dependency involving one or more Essential packages that causes apt (and therefore aptitude) to bail out. What is not so nice is that apt provides no real information on *why* the bail out happens and continues to give the same (overly brief) error with *all* apt-based methods of trying to solve the problem. i.e. as far as apt is concerned, nothing can be done and apt condemns the entire installation as foobar. Not nice - especially when the error message is so unclear. At one point, 'apt-get -f install' recommends removing apt itself which isn't particularly helpful either. 4. The intuitive response of: apt-get install libstdc++6 fails (at least it does on amd64) because of a dependency on lib32gcc1 but trying to install both using apt or aptitude fails with the same internal error. OK, the solution: Within the Emdebian chroot (using --save-after-login), remembering that all the packages you need *are* available in /var/cache/apt/archives within the chroot (and at the correct versions), you do the majority of the fix via direct calls to '# dpkg --force-depends -i /var/cache/apt/archives/....' Packages to force on amd64: (Use tab completion for versions / architectures) /var/cache/apt/archives/libstdc++6_4.2.2-5_amd64.deb /var/cache/apt/archives/lib32gcc1_1%3a4.2.2-5_amd64.deb /var/cache/apt/archives/gcc-4.2-base_4.2.2-5_amd64.deb /var/cache/apt/archives/libstdc++6-4.2-dev_4.2.2-5_amd64.deb /var/cache/apt/archives/libgomp1_4.2.2-5_amd64.deb /var/cache/apt/archives/cpp-4.2_4.2.2-5_amd64.deb /var/cache/apt/archives/g++-4.2_4.2.2-5_amd64.deb /var/cache/apt/archives/gcc-4.2_4.2.2-5_amd64.deb /var/cache/apt/archives/libgcc1_1%3a4.2.2-5_amd64.deb /var/cache/apt/archives/libc6-i386_2.7-5_amd64.deb /var/cache/apt/archives/libc6_2.7-5_amd64.deb /var/cache/apt/archives/tzdata_2007k-1_all.deb After forcing the majority of build-essential, you can now return to apt: # apt-get upgrade # apt-get install libc6 # apt-get install libc6 libc6-dev # apt-get -f install # apt-get upgrade # apt-get dist-upgrade Just before you exit, just check that things are ok: # echo $? 0 and then exit: # exit Copying back the cached apt archive contents -> new cache content emdebian-tools_0.7.3_all.deb added ..... -> new cache content pbuilder_0.177_all.deb added -> Saving the results, modifications to this session will persist -> creating base tarball [/opt/emdebian/emdebian.tgz] Phew! If someone has a bright idea on the root cause, let me know. It seems to related to a combination of installing gcc-4.2_4.2.2-5 in an environment that is quite a bit older - I had no problems updating the main system, it was only this chroot (untouched for about 2 weeks as it was using emdebian-tools 0.6.2) that showed the problem. Of course, now that the chroot is fixed, there is no easy way of replicating the bug or finding out much more than I have already put above. Having said that, I do still have remnants of the extracted chroot because pbuilder was unable to rescue the environment and repackage it. -- Neil Williams ============= http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/
Attachment:
signature.asc
Description: This is a digitally signed message part