kubuntu Hardy Heron could not install libc6

[ibrent]

Binary package hint: update-manager

1) running:
lsb_release -rd
Description: Ubuntu 7.10
Release: 7.10
2) upgrading to Hardy Heron beta
3) expected a clean upgrade
4) go:
Error panel
title: Could not install 'libc6'
The upgrade will continut but the 'libc6' package may be in a not working state. Please consider submitting a bugreport about it.
Conents of the panel:
subprocess post-installation script killed by signal (Segmentation fault), core dumped

[Kelly-Propelly (kelly-propelly)]

Confirmed. I had the same bug doing an upgrade from Kubuntu 7.10 to Kubuntu 8.04 (beta).

[NoHands (celavibezruku)]

Same here

[Rainer Eli (claushellsing)]

uups yes i've got the same error...

[Adolfo Fitoria (aj-fitoria)]

see the attachment for the error message output

[Sense Egbert Hofstede (sense)]

Thank you for reporting this bug. It is confirmed but before I set it that way I want to ask for some more information. If even one replies with that information this bug can we considered as confirmed. Please attach the following files:
/var/log/dist-upgrade/main.log
/var/log/dist-upgrade/apt.log
/var/log/dist-upgrade/term.log
This can help us decide if this bug is really in update-manager or maybe in libc6.

Thanks in advance.

[Richard Finegold (goldfndr)]

Attached: logfiles.tgz; tar cvzf /tmp/logfiles.tgz apt.log main.log term.log

Unfortunately, before reading this, I'd clicked Close, so I got the next message box:

Could not install '/var/cache/apt/archives/libc6-i686_2.7-9ubuntu2_i386.deb'
The upgrade will continue but the '/var/cache/apt/archives/libc6-i686_2.7-9ubuntu2_i386.deb' package may be in a not working state. Please considier submitting a bugreport about it.
pre-dependency problem - not installing libc6-i686

Clicking Close might be why term.log is zero length. Or perhaps not.

[Richard Finegold (goldfndr)]

Just to follow up on this, the following is in the terminal but doesn't seem to be in main.log:

Removing xbiff ...
Removing xcalc ...
Removing xclipboard ...
Removing xclock ...
Removing xconsole ...
(Reading database ... 154624 files and directories currently installed.)
Preparing to replace libc6-dev 2.6.1-1ubuntu10 (using .../libc6-dev_2.7-9ubuntu2_i386.deb) ...
Unpacking replacement libc6-dev ...
Preparing to replace libc6 2.6.1-1ubuntu10 (using .../libc6_2.7-9ubuntu2_i386.deb) ...
Unpacking replacement libc6 ...
Setting up libc6 (2.7-9ubuntu2) ...
Installing new version of config file /etc/init.d/glibc.sh
Installing new version of config file /etc/gai.conf ...
*** stack smashing detected ***: /usr/bin/perl terminated
dpkg : error processing libc6 (--configure):
 subprocess post-installation script killed by signal (Segmentation fault), core dumped
Errors were encountered while processing:
 libc6
dpkg: regarding .../libc6-i686_2.7-9ubuntu2_i386.deb containing libc6-i686, pre-dependency problem:
 libc6-i686 pre-depends on libc6 (= 2.7-9ubuntu2)
  libc6 latest configured version is 2.6.1-1ubuntu10.
dpkg: error processing /var/cache/apt/archives/libc6-i686_2.7-9ubuntu2_i386.deb (--unpack):
 pre-dependency problem - not installing libc6-i686

That "*** stack smashing detected ***: /usr/bin/perl terminated line" is quite disconcerting.
Also, I recently did an apt-get upgrade which had two instances of the following lines:

Processing triggers for libc6 ...
ldconfig deferred processing now taking place

[psylem (subnetjet)]

I have this problem, attaching logs...
/var/log/dist-upgrade/main.log

[psylem (subnetjet)]

/var/log/dist-upgrade/apt.log

term.log is empty

[Michael Vogt (mvo)]

Thanks for your bugreports.

I confirm this on the grounds that we have two logs that show the same problem:

2008-03-22 17:22:34,019 ERROR got an error from dpkg for pkg: 'libc6': 'subprocess post-installation script killed by signal (Segmentation fault), core dumped'

Could you please tell us what version of libc6 in hardy you got? Is /var/log/dist-upgrade/term.log empty for all of you?

Thanks,
 Michael

[Michael Vogt (mvo)]

Based on:

Unpacking replacement libc6 ...
Setting up libc6 (2.7-9ubuntu2) ...
Installing new version of config file /etc/init.d/glibc.sh
Installing new version of config file /etc/gai.conf ...
*** stack smashing detected ***: /usr/bin/perl terminated
dpkg : error processing libc6 (--configure):
 subprocess post-installation script killed by signal (Segmentation fault), core dumped
Errors were encountered while processing:
 libc6

I suspect its a problem with python-qt/kde and the debconf kde frontend.

[psylem (subnetjet)]

Here's a screen shot of the libc6 package in Adept in the broken state after the failed upgrade incident.

Another package that also appears broken in my list is "xbase-clients". My system still appears reasonably unaffected by the failure although Adept wanted to update via Hardy sources. I've since switched back to Gutsy sources until this bug is resolved, then I'll attempt to resume the upgrade from scratch again).

[Richard Finegold (goldfndr)]

For what it's worth, I seem to have worked around it with the following commands:

cd /var/cache/apt/archives
sudo dpkg -i libgcc1_1%3a4.2.3-2ubuntu4_i386.deb libc6_2.7-9ubuntu2_i386.deb

Neither libc6 nor libgcc1 would install on its own; they both needed to be installed in a single "dpkg -i" command.

After that, "apt-get -f install" was complaining about debconf. Again, multiple packages needed to be installed simultaneously:

sudo dpkg -i debconf* liblocale-gettext-perl_* perl-base_*

And after those, "apt-get -f install" seemed okay. Now continuing with "sudo apt-get dist-upgrade" (crossing fingers)...

[Note: I'm not, by any means, an expert or even a professional at this; consider waiting for a second opinion before forcing installs of packages.]

[Richard Finegold (goldfndr)]

Aborted out of "sudo apt-get dist-upgrade", instead I'm trying the following command, as recommended elsewhere (and I'd tried originally):

kdesu "adept_manager --dist-upgrade-devel"

[Richard Finegold (goldfndr)]

For what it's worth, the 'kdesu "adept_manager --dist-upgrade-devel"' command worked fine. Went thru the rest of the packages, had me restart, went thru the standard fsck (after 125 days uptime) which seemed to stall at 10%, then another restart while I wasn't looking, all seems well.

[Jon Wooten (jmwooten)]

I had same problem when upgrading from 7.10 to 8.04 beta.

Ultimately, I did a clean install of 7.10 and as a result it called for a lot updates ( so it would be current).

Encountered the same issue (broken dependencies) when the updates attempted to install.

It left my adept manager running in the background. Ran "dpkg -- configure -a" to attempt to correct.

[Matthias Rampke (matthias-rampke)]

Same problem updating Kubuntu 7.10 to 8.04beta by adept_manager as recommended. term.log is zero length, but there is an additional apt-term.log (featuring some very, uhm, creative german localization) containing the output in the update-manager terminal.

I'll try Richard's workaround.

[Matthias Rampke (matthias-rampke)]

Addition to previous post: I checked term.log _before_ I clicked close, it was zero length then as well.

Richard's workaround worked fine.
Even after closing the update-manager, warnings about packages not installed due to failed dependencies kept coming up until I killed the corresponding python processes. Then everything worked fine, except for the -386 kernel waiting for the root filesystem indefinitely. -generic worked, and this is probably unrelated.
So, here's a short wrap-up of the workaround process, starting from when you get the offending message (preceding # means no shell input):

#close the error window; click the close button on the update-manager window and confirm. more error windows might pop up
ps ax #show all processes
#there will be one or more "python /tmp/*"-like processes. kill all of them.
cd /var/cache/apt/archives
sudo dpkg -i libgcc1_* libc6_*
sudo dpkg -i debconf* liblocale-gettext-perl_* perl-base_*
apt-get -f install
kdesu "adept_manager --dist-upgrade-devel"
# wait for it to finish, reboot when requested, wait for fsck and automatic second reboot, enjoy 8.04!
# if needed choose "generic" kernel

[nitrogen (i-am-nitrogen)]

Another vote for this bug.

First the segmentation fault error, then this error in another dialog:

Could not install '/var/cache/apt/archives/libc6-i686_2.7-9ubuntu2_i386.deb'
...
pre-dependency problem - not installing libc6-i686

And this error for libgcc1, libstdc++6, libncurses5, and others (which makes sense):

dependency problems - leaving unconfigured

[STaRMaN (jarizaro)]

Some here...
repaired with "dpkg -- configure -a" as said Jon Wooten.
and later:
  first) running sudo apt-get install -f
  second) running sudo apt-get dist-upgrade

[Matthias Klose (doko)]

please could somebody test, if removing the non-tls library (and moving the tls one to /usr/lib) is a solution? hardy has tls support.

[Matthias Klose (doko)]

ohh, in nvidia-glx of course

[Eric Katz (eric-katz)]

Had the same problem. This one is pernicious. Whether you abort the install or let it finish, the system is left in a VERY unstable state.

[Matthias Klose (doko)]

please recheck with the nvidia-glx (or nvidia-glx-new) package from http://people.ubuntu.com/~doko/tmp/lrm-hardy/

[Launchpad Janitor (janitor)]

This bug was fixed in the package linux-restricted-modules-2.6.24 - 2.6.24.12-15.33

---------------
linux-restricted-modules-2.6.24 (2.6.24.12-15.33) hardy; urgency=low

  [ Matthias Klose ]
  * nvidia-glx: Install the TLS library in /usr/lib, symlink the one in
    /usr/lib/tls to the one in /usr/lib. LP: #205079.

 -- Timo Aaltonen <email address hidden> Fri, 04 Apr 2008 16:59:50 +0300

[Michael Vogt (mvo)]

Thanks for the additional information.

It looks like everybody with the crash had nvidia-glx-new installed. Was that also the driver in use when the crash happend? If so, did you install nvidia-glx-new from the ubuntu archive or via some other method? I ask to be able reproduce it more easily.

Thanks,
 Michael

[Michael Vogt (mvo)]

Could you please attach the output of:
$ ls -l /etc/ld.so.nohwcap

[Robin Garner (robin-garner)]

Mine was installed from the ubuntu archives. Recently (ie Monday 31 Mar).

cheers

Michael Vogt wrote:
> Thanks for the additional information.
>
> It looks like everybody with the crash had nvidia-glx-new installed. Was
> that also the driver in use when the crash happend? If so, did you
> install nvidia-glx-new from the ubuntu archive or via some other method?
> I ask to be able reproduce it more easily.
>
> Thanks,
> Michael
>
>

[Robin Garner (robin-garner)]

Michael Vogt wrote:
> Could you please attach the output of:
> $ ls -l /etc/ld.so.nohwcap
>
>
# ls -l /etc/ld.so.nohwcap
ls: cannot access /etc/ld.so.nohwcap: No such file or directory

# ls /etc/ld*
/etc/ld.so.cache /etc/ld.so.conf

/etc/ldap:
ldap.conf

/etc/ld.so.conf.d:
i486-linux-gnu i486-linux-gnu.conf libc.conf

[Matthias Rampke (matthias-rampke)]

I can confirm using nvidia-glx-new. I had installed it (in 7.04) via the Hardware Drivers Manager. It was active during the upgrade.

The System upgraded through the workaround (see above) works just fine, no (related) problems encountered.

[Michael Vogt (mvo)]

I can reproduce this behavior here with a kubuntu gutsy install with nvidia-glx-new installed, setting to high priority as this may affect a lot of people.

[Pas (pasthelod)]

Same problem here.

I've installed a 7.10 Ubuntu, then KDE and KDE4. They got along rather nice. I'm also using the nvidia GLX driver.

[ibrent (brent-laminack)]

yes, i believe i was using it. I also believe i in stalled it from the
archive.

brent

On Fri, Apr 11, 2008 at 4:08 AM, Michael Vogt <email address hidden>
wrote:

> Thanks for the additional information.
>
> It looks like everybody with the crash had nvidia-glx-new installed. Was
> that also the driver in use when the crash happend? If so, did you
> install nvidia-glx-new from the ubuntu archive or via some other method?
> I ask to be able reproduce it more easily.
>
> Thanks,
> Michael
>
> --
> kubuntu Hardy Heron could not install libc6
> https://bugs.launchpad.net/bugs/205079
> You received this bug notification because you are a direct subscriber
> of the bug.
>

[Pas (pasthelod)]

Regarding the nvidia-glx. I was using it, I'm sure. I think I enabled it via the "restricted drivers manager", and it upgraded itself via adept/synaptic at times (I suppose).

[icorbett (icorbett)]

Michael,

I also have the nvidia-glx-new package installed and used. It was
installed via the restricted drivers manager since 7.04 and upgraded to
7.10 previously without trouble.

-(icorbett@sin)-(07:31 AM 11/04/08)--
-(~)$ ls -l /etc/ld.so.nohwcap
ls: cannot access /etc/ld.so.nohwcap: No such file or directory
-(icorbett@sin)-(07:31 AM 11/04/08)--
-(~)$ ls -l /etc/ld.so*
-rw-r--r-- 1 root root 73623 2008-04-10 13:09 /etc/ld.so.cache
-rw-r--r-- 1 root root 35 2008-03-23 19:59 /etc/ld.so.conf

/etc/ld.so.conf.d:
total 12
-rwxr-xr-x 1 root root 64 2006-10-10 10:33 i486-linux-gnu
-rw-r--r-- 1 root root 64 2008-03-13 08:32 i486-linux-gnu.conf
-rw-r--r-- 1 root root 44 2007-07-23 17:06 libc.conf

Regards,
Ian

Michael Vogt wrote:
> Could you please attach the output of:
> $ ls -l /etc/ld.so.nohwcap
>

[Michael Vogt (mvo)]

Thanks, I can reproduce the crash here too with nvidia-glx-new. I reported #215684 (probably a unreleated crash, libqt-perl seems to be not very stable), #215660, #215687 with the crashes. perl -e 'use Qt' triggers the crash now.

[Michael Vogt (mvo)]

To reproduce (on a nvidia gutsy kubuntu):

$ sudo touch /etc/ld.so.nohwcap
$ perl -e "use Qt"

The fix in hardy is to change linux-resticted-modules line this:
  [ Matthias Klose ]
  * nvidia-glx: Install the TLS library in /usr/lib, symlink the one in
    /usr/lib/tls to the one in /usr/lib. LP: #205079.

This either needs backporting to gutsy or we modify it on the fly in update-manager
during the dist-upgrade.

[Michael Vogt (mvo)]

Indeed removing /usr/lib/libnvidia-tls.so.1 and symlinking it ot /usr/lib/tls/nvidia-tls.so.100.14.19 works just fine, my upgrades runs then.

[Michael Vogt (mvo)]

update-manager (1:0.87.17) hardy; urgency=low

  * DistUpgrade/DistUpgradeView.py:
    - work around gutsy->hardy nvidia-glx uprade problem
      when libqt-perl is used (#205079)

The above upload in update-manager works around the issue during the upgrade. The new linux-restricted-modules package (in hardy) only ships the TLS version of the libraries. Based on this I close the bugreport.