Upgrade tool crashed with " Cannot allocate memory"

[Bradley T Hughes]

Ever since feisty, the release upgrade tool fails with "OSError: [Errno 12] Cannot allocate memor" on some systems. This has been reported for both the KDE, Gnome and console programs.

The problem is reproducible with the current Jaunty -> Karmic upgrade as well.

[ description cleaned up to summarize comments and current status ]

[Michael Vogt (mvo)]

Thanks for your bugreport.

It looks like the machine ran out of memory. How much memory/swap do you have ?

Thanks,
 Michael

[Bradley T Hughes (bhughes)]

1G of memory, 3G of swap. At the time of the upgrade, the only thing that was running was Konsole and the upgrader. The upgrade seems to have succeeded, and I don't know how to reproduce the problem, should I need to :/

[Michael Vogt (mvo)]

Uh, that should be plenty of resources. I do the upgrade tests on a 256 mb test machine. Was there anything else runing that could have used up a lot of memoty?

[Bradley T Hughes (bhughes)]

I don't believe so. There could have been a process running in the background that might have taken some memory (g++), but I've never had OOM situations on this laptop before while doing rebuilds of the Qt 4 library. We may just have to shrug this one off as a fluke. :/

[Stephan (stephan-h)]

Exact same situation here.
- up-to-the-minute update within edgy
- use update-manager to upgrade to feisty
- no other processes
- 1G of RAM
-> "Cannot allocate memory"

NB.: I'm using Kubuntu.

(Then a window asks me to enter this as a bug to launchpad, which of course
doesn't work, because upgrade just shut down the internet connection ;-).

Should I upload my log files, too?

Also #107727 looks like the same problem?

[Michael Vogt (mvo)]

I was not able to reproduce this on a 256MB RAM/377MB SWAP machine (no other aps runing when the upgrade was runing, only adept). I also tried it with amarok, kmail and konqoror runing in the background and got no memeory expection.

[Jonathan Riddell (jr)]

What version of KDE did you have installed in Edgy? what stage was the installer at when it crashed?

[Tirsel Martin (bruce-wardogs)]

if it hleps, the upgrader crashed after i confirmed to remove some obsolote packages (i had php4, but i cant remember if it was in this remove box). It seems that the upgrade was succesfull (system is working ok) and the only problem was these packages, which i removed afterwards manually. Is there any way to checkif the upgrade was ok?

[Stephan (stephan-h)]

Hi,

> What version of KDE did you have installed in Edgy?
3.5.5 to the best of my knowledge (the latest in Kubuntu Edgy)
> what stage was the installer at when it crashed?

must have been close to finish.
After reboot the system seems to be properly setup.

The last interaction as far as I remember was about bcm43xx-fwcutter.
Last entry in main.log before the crash is
The following packages are remove candidates: libapr0 linux-headers-2.6.17-11-generic libdns21 libgpod0 ndiswrapper-utils libavahi-core4 acroread libdirectfb-0.9-24 linux-heade
rs-2.6.17-10 libopenobex-1.0-0 grepmap libicu34 ndiswrapper-utils-1.8 linux-headers-2.6.17-10-generic libsvn0 linux-headers-2.6.17-11 libsvnqt2 ndiswrapper-utils-1.1 libtunepimp3
There was a dialog asking for confirmation, I remember now, where I answered OK.

(attaching the file)

regards,
Stephan

[Michael Vogt (mvo)]

Everyone bitten by this bug has a complete upgrade, its just that some old package have not be removed.

[Michael Vogt (mvo)]

This problem might be releated to a network failure during the download of the packages. Most logs seem to have one (but at least one does not have it). But it might be something to try to reproduce it.

[Stephan (stephan-h)]

The only warnings I could find in my main.log are

WARNING no activity on terminal for 240 seconds (Configuring libssl0.9.8)
WARNING no activity on terminal for 240 seconds (Configuring bcm43xx-fwcutter)

In fact I was away from the machine for more than 3 minutes during upgrade.

How would a network problem show up?

[Michael Vogt (mvo)]

Could this be theme releated? What theme do you use?

[Yann (yannlieb)]

For me, problem occured after upgrade-manager got stuck with interaction for package lm-sensors. I had to kill this post-intall thread, update manager went on till the end of install phase and then crashed when arriving to clean-up phase.

Please note that I had previously applied the "kde-356-pre-feisty-upgrade" in order to run the upgrade

[bertkenward (bert-kenward)]

Just to add to this, I've had similar behaviour. Running KDE 3.5.5. An aptitude upgrade run after a reboot removed three packages, and it's fine.

Following up from Stephan's comment about being away from the machine for a while, I left this to work for a while, and there was generally a question from dpkg when I got back.

[DavidWhyte (dave-whyte)]

I had this crash in the clean up stage after I confirmed to remove some obsolete packages

Error trace nearly identical to the one above.

[DJ Brown (speaker2software)]

Hello Michael:

    <<Could this be theme releated? What theme do you use?>>

Unlikely. The chance that we are all using the same theme is
vanishingly small... unless we're all using the default KDE
theme.

I *was* using the default theme, though I tried several on when
exploring those options. I also made a few minor tweaks (that I
understood, being a noob) and posted the V.I.S.T.A. wall paper.
Other than that, it was pretty much default KDE.

According to another message I received this morning, there were
instructions to (manually?) install 2 upgrades before proceeding
with the install. I *believe* my failure to do this is the more
likely cause.

DJ Brown
   Austin, TX

-----Original Message-----
From: <email address hidden> [mailto:<email address hidden>] On
Behalf Of Michael Vogt
Sent: Saturday, April 21, 2007 2:16 AM
To: <email address hidden>
Subject: [Bug 107188] Re: [MASTER] [kde] Upgrade tool crashed
(edgy -> feisty)

[snipped]

[fim (brassel)]

I experienced a complete system crash after starting the upgrad edgy to feisty. Now I cannot boot anymore and (sniff) have to resort to windows to add to this bug list. I do not even know how to retrieve any log files or personal data which went down with my system.

[Marko (argus)]

I also got a crash during full upgrade.

Maybe a network error was the reason. I use Wifi for my computer (I hate all those cables in my house), and this has been a bit buggy from time to time...

[Dermot (dd2)]

Here's some additional info. which might provide some clues.

I was running Kubuntu 6.10 with all current updates installed on 19-Apr. I was using default KDE theme. I have a Broadcom Wireless card and was using ndiswrapper.

The upgrade proceeded correctly and all 600-800 packages were downloaded and installed. The Upgrade tool then entered the cleanup phase. I received a couple of dialog boxes about overwriting configuration files (one was about /etc/modprobe.d/blacklist). I then received a dialog asking permission to remove obsolete packages which I allowed. I believe (but am not 100% certain) that this went OK and I then got a second dialog asking permission to remove obsolete packages. So I either got one (definitely) or two (probably) dialogs re. obsolete packages and said OK.
I remember that one of the packages to be removed on the last dialog was ndiswrapper-utils. The Upgrade tool then crashed when it ran out of memory with 1.1GB physical memory and 2GB swap on my laptop. No other applications were running except Konsole. I use network-manager to manage my network connections.

After restarting I can see that I have ndiswrapper-utils1.8 amd ndiswrapper1.9 installed so it seems like the Upgrade tool crashed either before or during removing this.

I see that Stephen mentioned bcm43xx-fwcutter. I wonder how many people who have experienced this bug are running Broadcom WiFi cards with fwcutter or ndiswrapper?

Dermot.

[Heiko Hänsel (hhaensel)]

Hi,

in my case the Upgrade Tool crashed in the phase "clean up". The last interaction was that it asked me to confirm the removal of some unsupported packages.

[Tzvetan Mikov (tmikov)]

Encountered the same problem today - the stack trace is exactly the same. If necessary I can upload my log files.

[Tzvetan Mikov (tmikov)]

Forgot to add some details: I ran "aptitude dist-uprade" after the crash and everything is fine now - I am happily running Feisty.
I don't think is related to with wireless networking, but for the record my laptop is with Intel 3945ABG.

[Calabacin (raulgarciag)]

Hi

I just got this same problem. I do not have any wireless configured, I am connected to a LAN router. I did not lose connectivity after the crash, and I am in fact writing this from my Kubuntu system, that seems to work fine.

After confirming I wanted to uninstall those old packages it just stopped working. Before I got any crash report I tried to open a folder clicking on it on the desktop, but it wouldn't work. Just waited there until I got that out of memory error message and a moment afterwards Konkeror finally opened.

These are the packages that were to be uninstalled:
libgnucrypto-java
libgtkhtml3.8-15
libjaxp1.2-java
libkexif1
libpq4
libsasl2
libstlport4.6c2
python-elementtree
wlassistant
xkeyboard-config

--------------------------------------
This is the error message I got:
Traceback (most recent call last):
  File "/tmp/kde-root/adept_updaterQGzWCb.tmp-extract/dist-upgrade.py", line 56, in ?
    app.run()
  File "/tmp/kde-root/adept_updaterQGzWCb.tmp-extract/DistUpgradeControler.py", line 1025, in run
    self.fullUpgrade()
  File "/tmp/kde-root/adept_updaterQGzWCb.tmp-extract/DistUpgradeControler.py", line 1014, in fullUpgrade
    self.doPostUpgrade()
  File "/tmp/kde-root/adept_updaterQGzWCb.tmp-extract/DistUpgradeControler.py", line 740, in doPostUpgrade
    res = self.cache.commit(fprogress,iprogress)
  File "/usr/lib/python2.4/site-packages/apt/cache.py", line 204, in commit
    if res == pm.ResultCompleted:
  File "/usr/lib/python2.4/site-packages/apt/cache.py", line 179, in installArchives
    installProgress.finishUpdate()
  File "/usr/lib/python2.4/site-packages/apt/progress.py", line 206, in run
    select.select([self.statusfd],[],[], self.selectTimeout)
  File "/tmp/kde-root/adept_updaterQGzWCb.tmp-extract/DistUpgradeViewKDE.py", line 227, in fork
    self.child_pid = os.fork()
OSError: [Errno 12] Cannot allocate memory

And here are the log files:
http://calabacin.es/ubuntu/apt.log
http://calabacin.es/ubuntu/main.log

I have 22GB of free HD, 1GB RAM and 2.2Gb swap.

I cannot say if my system will reboot, but I'm about to find out!

[Tarski (supereddy)]

Same problem after 4 hours of downloading/upgrading. I started a new bug thread because the update manager instructed me to

https://bugs.launchpad.net/ubuntu/+source/update-manager/+bug/109074

[obotor (bonnet-o)]

I connect through Wireless LAN. After the crash everything seems ok. The computer has 1.5 GB RAM and about 900MB swap (which is rarely used indeed). It has not lost any connectivity - as can be noticed.

I remember that among the so-called obsolete packages were (* correspond to forgotten chars, (?) means that I am not 100% sure of the name):
acroread
acroread-esw***** (?)
acroread-pck**** (?)
...
libmysql14
libphp4
...
libssl**
...
xkeyboard-config

Here is the trace in the upgrade manager:

Traceback (most recent call last):
  File "/tmp/kde-root/adept_updatertujGJb.tmp-extract/dist-upgrade.py", line 56, in ?
    app.run()
  File "/tmp/kde-root/adept_updatertujGJb.tmp-extract/DistUpgradeControler.py", line 1025, in run
    self.fullUpgrade()
  File "/tmp/kde-root/adept_updatertujGJb.tmp-extract/DistUpgradeControler.py", line 1014, in fullUpgrade
    self.doPostUpgrade()
  File "/tmp/kde-root/adept_updatertujGJb.tmp-extract/DistUpgradeControler.py", line 740, in doPostUpgrade
    res = self.cache.commit(fprogress,iprogress)
  File "/usr/lib/python2.4/site-packages/apt/cache.py", line 204, in commit
    if res == pm.ResultCompleted:
  File "/usr/lib/python2.4/site-packages/apt/cache.py", line 179, in installArchives
    installProgress.finishUpdate()
  File "/usr/lib/python2.4/site-packages/apt/progress.py", line 206, in run
    select.select([self.statusfd],[],[], self.selectTimeout)
  File "/tmp/kde-root/adept_updatertujGJb.tmp-extract/DistUpgradeViewKDE.py", line 227, in fork
    self.child_pid = os.fork()
OSError: [Errno 12] Ne peut allouer de la mémoire ( --> meaning Cannot allocate memory)

[obotor (bonnet-o)]

After a restart everything seems to be alright including all server stuff and databases. No further step has been required so far.

[Alan (alan-fitzgerald)]

I was in a mess after this happened to me. KDE was only half installed, I have no idea what state everything else is in. I reinstalled KDE, but kdeinit was still missing a bunch of libs. After reloading each of these I have KDE up and runnning again...o and startkde was no longer being called.

This has been a nightmare. This Linux box has been my primary box in an all Windows shop for 2 years. I had no response to the question, "what would a normal user do if this happened to them?". I need to get this straightened out asap, I have already lost 2 days of work. I would hate this to force me to run Windows there again.

My original bug was:
https://bugs.launchpad.net/ubuntu/+source/update-manager/+bug/109328

[madamos (madamos)]

After a restart things appear to be functioning normally for me.

[DJ Brown (speaker2software)]

Agreed Madamos:

I don't exactly trust it yet but KDE seems to come up normally
and run just fine except for a few missing items - things that
ran fine in the previous install but are missing now. I'll have
to do a bit of an inventory but I can come up with a list.

Alas, there are a couple of problems that continue: one is the
Adept (?) program installer that dumps mysteriously when I check
the two boxes at the upper right looking for all the available
application downloads. It takes a few seconds but the window just
pops away with no warning or crash report.

Still, I'm in the enviable position of being able to leave the
machine in its original failed condition in case any of the
Ubuntu diagnostic staff want to pick it apart.

DJ Brown
   Austin, TX

-----Original Message-----
From: <email address hidden> [mailto:<email address hidden>] On
Behalf Of madamos
Sent: Wednesday, April 25, 2007 8:19 AM
To: <email address hidden>
Subject: [Bug 107188] Re: [MASTER] [kde] Upgrade tool crashed
(edgy -> feisty)

After a restart things appear to be functioning normally for me.

[Snipped] <belch!> Good stuff!

[SOON (dsl395035)]

I've noticed since my upgrade from 6.10 til 7.04, that my package lists
i adept is screwed up: I see a package (e.g Compiz) but the description
listed is for something completely different (in this case the OFFIS
DICOM commandline toolkit) ... whats going on there?!?

--
Med venlig hilsen / Kind regards
Søren O'Neill

Kiropraktor, klinisk lektor
Søren O'Neill, DC, M.Rehab, Stud.PhD
Rygcenter Fyn, Lindevej 5
5750 Ringe

mail (arb./work) <email address hidden>
mail (hjem/home) <email address hidden>

tel. (arb./work) [phone]
tel. (hjem/home) [phone]
tel. (mobile) [phone]

[AllisterX (allister-sanchez)]

I got the same "Upgrade Tool Crashed" too after I clicked to remove obsolete packages. Exactly same message. And I got this from a newly installed edgy that is immediately upgraded to feisty. (I botched my first attempt to upgrade.)

[madamos (madamos)]

Hmm, that was the same thing for me. The remove obsolete packages -
thanks for reminding me.

I'm also having a problem on a clean system with adept not starting
but not really crashing either, just kdesu hanging out in memory and
then adept not starting until I reboot.

On 4/25/07, AllisterX <email address hidden> wrote:
> I got the same "Upgrade Tool Crashed" too after I clicked to remove
> obsolete packages. Exactly same message. And I got this from a newly
> installed edgy that is immediately upgraded to feisty. (I botched my
> first attempt to upgrade.)
>
> --
> [MASTER] [kde] Upgrade tool crashed (edgy -> feisty)
> https://bugs.launchpad.net/bugs/107188
> You received this bug notification because you are a direct subscriber
> of a duplicate bug.
>

--
Usually I try to take it one day at a time, but lately several have
attacked me at once...

[BobRobison (bob-robison)]

Same as others above -- I had the memory allocation error in DistUpgradeViewKDE.py, shortly after the screen that asks about removing packages. However, when I tried to reboot, grub was hosed up.

In my case, the problem was that the grub device names had changed. Previously in grub menu.lst I had root (hd1,0), which would no longer boot. I changed it to root (hd0,0) and then it booted OK. I have an ide disk in place, and a scsi -- and I wanted to boot off the scsi. Now, (after booting), the IDE drive shows up as /dev/sda, and the first scsi disk has shifted to /dev/sdb... ? However, the order is still the same, so I'm not sure why the grub change was needed.

[mvsjes2 (robin-robinandmariette)]

Just want to add...

I did an upgrade about four times from edgy to feisty and ran into the same problem each time. It was the same machine/config, I restored back each time with a clone tool. I have 512meg of ram and 2gig swap drive. I ran the last upgrade with the swap file monitor running. It was barley used during the whole upgrade (between 50-300k), and when it got to the step where it asked to do the cleanup and I clicked OK, the swap usage climbed over about 10 seconds to 1.4gig before the upgrade tool crashed. Pretty much identical logs to the above.

The last attempt I made I used an AptOnCD dvd to hold my apt sources, so the network was not/barely used. Same result.

[Tzvetan Mikov (tmikov)]

I have a couple Kubuntu machines in our office to waiting to be upgraded, but I am putting that on hold for now. I can't risk it - apparently here some people's machines were hosed after the crash (shouldn't there be something on the main site, to warn people temporarily against upgrading). It is an unpleasant situation.

Is there any information available on what causes this, or workarounds ?

For example, won't it be better to use the "old" way of upgrading with "aptitude dist-upgrade" - that has never failed me before. I would be very surprised if it crashed.

[Marc Dekenah (m-marcspages)]

mvsjes, you beat me to it. I was going to set up a log on another 6.10 machine that needs to be "feistied" and see when/what goes crazy at the point of crash. But this raises another small issue; It's all very well to say "you need to do a manual clean-up" (oh yes, I'm all for keeping disk clear of junk), but please give us "intermediates" (not noobie, but not Linux boff either) a little help as to where we need to wield the cyber-broom. Ta, ever so ta.

I'm going to upgrade this other machine but not remove obsolete packages and see what occurs.

M.

[DJ Brown (speaker2software)]

Hello Tzvetan:

    <<For example, won't it be better to use the "old" way of
    upgrading with "aptitude dist-upgrade" [apt dist-upgrade...]
    I would be very surprised if it crashed.>>

I'd try the "apt dist-upgrade" command as well. Who knows *what*
will work at this stage? Sadly, you risk one more machine if it
fails again.

In most other respects, the KDE upgrade on the main computer is
perfect except for the upgrade crash.

Wonder what steps I (we) missed after the crash? ...and can the
upgrade tool be re-started to finish the job or can we replicate
the missed steps manually?

DJ Brown
   Austin, TX

In the meantime...
The format and re-install of Gnome on my other machine went
famously though I'm puzzled. The upgrade tool found my LAN, the
Internet, an existing install of Win2K, got the Grub setup
correct and yet failed to install Samba?!?!? That feels more like
a design choice rather than program failure, though.

-----Today's Mantra-----
It is by Caffeine alone I set my mind in motion,
It is by the beans of Java, that my thoughts acquire speed,
My hands acquire shaking; the shaking becomes a warning,
It is by Caffeine alone I set my mind in motion...
  ~~The Mentat's Mantra (Shamelessly adapted)
  from the Dune series, Frank Herbert

-----Original Message-----
From: <email address hidden> [mailto:<email address hidden>] On
Behalf Of Tzvetan Mikov
Sent: Thursday, April 26, 2007 1:00 PM
To: <email address hidden>
Subject: [Bug 107188] Re: [MASTER] [kde] Upgrade tool crashed
(edgy -> feisty)

[Snipped... More bandwidth for the botnets <blek!>]

[mvsjes2 (robin-robinandmariette)]

Marc,

After the upgrade, go to /var/log/dist-upgrade/main.log. Just before the crash entries at the end of the log, you'll see a list of packages that were flagged for removal.

Just "sudo apt-get remove --purge copy/paste the list of packages here"

and you should be good to go.

For the record, I did this four time and it never hosed my system, the upgrade itself went very smoothly. I also did my buddy's system and didn't run into this error, it went very smoothly.

[Marc Dekenah (m-marcspages)]

Hi Robin,

I realized after posting my comment you could very well has read that
I asked you personally for assistance as opposed to getting the "team
at the top" (Canonical) to post a workaround - but my heartfelt
thanks for doing this. Many will benefit from your advice.

Although I am new to Linux (6 months), I've delved under the bonnet a
lot to see how this motor works - being an old DOS bred guy it's just
so great to have an operating system that behaves itself again.

Again, my sincere thanks,
M.

_____________________________________________________________________
Recd: Thursday, 26 April 2007
From: mvsjes2
To: <email address hidden>
Subj: [Bug 107188] Re: [MASTER] [kde] Upgrade tool crashed (edgy ->
feisty)

Marc,

After the upgrade, go to /var/log/dist-upgrade/main.log. Just before
the
crash entries at the end of the log, you'll see a list of packages
that
were flagged for removal.

Just "sudo apt-get remove --purge copy/paste the list of packages
here"

and you should be good to go.

For the record, I did this four time and it never hosed my system, the
upgrade itself went very smoothly. I also did my buddy's system and
didn't run into this error, it went very smoothly.

--
[MASTER] [kde] Upgrade tool crashed (edgy -> feisty)
https://bugs.launchpad.net/bugs/107188
You received this bug notification because you are a direct subscriber
of a duplicate bug.

[tdn (spam-thomasdamgaard)]

I think I have the same bug.

I tried upgrading from edgy to feisty.
I am using Kubuntu.
I use LUKS for encrypted rootfs.

This is what I got:

We're sorry; the upgrade tool crashed. Please file a new bug report at

https://launchpad.net/distros/ubuntu/+source/update-manager/+filebug

(do not attach your details to any existing bug) and a developer will attend to the problem as soon as possible. To help the developers understand what went wrong, include the following detail in your bug report, and attach the files /var/log/dist-upgrade/apt.log and /var/log/dist-upgrade/main.log:

-----
Traceback (most recent call last):
  File "/tmp/kde-root/adept_updaterHF8fda.tmp-extract/dist-upgrade.py", line 56, in ?
    app.run()
  File "/tmp/kde-root/adept_updaterHF8fda.tmp-extract/DistUpgradeControler.py", line 1025, in run
    self.fullUpgrade()
  File "/tmp/kde-root/adept_updaterHF8fda.tmp-extract/DistUpgradeControler.py", line 1014, in fullUpgrade
    self.doPostUpgrade()
  File "/tmp/kde-root/adept_updaterHF8fda.tmp-extract/DistUpgradeControler.py", line 740, in doPostUpgrade
    res = self.cache.commit(fprogress,iprogress)
  File "/usr/lib/python2.4/site-packages/apt/cache.py", line 204, in commit
    if res == pm.ResultCompleted:
  File "/usr/lib/python2.4/site-packages/apt/cache.py", line 179, in installArchives
    installProgress.finishUpdate()
  File "/usr/lib/python2.4/site-packages/apt/progress.py", line 206, in run
    select.select([self.statusfd],[],[], self.selectTimeout)
  File "/tmp/kde-root/adept_updaterHF8fda.tmp-extract/DistUpgradeViewKDE.py", line 227, in fork
    self.child_pid = os.fork()
OSError: [Errno 12] Cannot allocate memory

-------------

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

updateStatus: Checking package manager
updateStatus: Updating repository information
WARNING: Failed to read mirror file
updateStatus: Checking package manager
updateStatus: Asking for confirmation
Installing libc6 as dep of mcpp
Installing kdelibs4c2a as dep of kpdf
Installing libasound2 as dep of kdelibs4c2a
Installing libcupsys2 as dep of kdelibs4c2a
Installing libfontconfig1 as dep of kdelibs4c2a
Installing fontconfig-config as dep of libfontconfig1
Installing libgcc1 as dep of kdelibs4c2a
Installing gcc-4.1-base as dep of libgcc1
Installing liblua50 as dep of kdelibs4c2a
Installing liblualib50 as dep of kdelibs4c2a
Installing libpng12-0 as dep of kdelibs4c2a
Installing libqt3-mt as dep of kdelibs4c2a
Installing libstdc++6 as dep of libqt3-mt
Installing libxrandr2 as dep of libqt3-mt
Installing libxml2 as dep of kdelibs4c2a
Installing libxslt1.1 as dep of kdelibs4c2a
Installing libgpg-error0 as dep of libxslt1.1
Installing kdelibs-data as dep of kdelibs4c2a
Installing xkb-data as dep of xkeyboard-config
Installing libatk1.0-0 as dep of gnome-keyring
Installing libglib2.0-0 as dep of libatk1.0-0
Installing libcairo2 as dep of gnome-keyring
Installing libdbus-1-3 as dep of gnome-keyring
Installing libpango1.0-0 as dep of gnome-keyring
Installing libpango1.0-common as dep of libpango1.0-0
Installing libdatrie0 as dep of libpango1.0-0
Installing libthai0 as dep of libpango1.0-0
Installing libthai-data as dep of libthai0
Installing libpopt0 as dep o...

[tdn (spam-thomasdamgaard)]

I want to add, that I have 1 GB of RAM.
My CPU is a 1.8GHz Pentium M.
My computer is an IBM Thinkpad T42.

Other info:

lspci:
~ $ lspci
00:00.0 Host bridge: Intel Corporation 82855PM Processor to I/O Controller (rev 03)
00:01.0 PCI bridge: Intel Corporation 82855PM Processor to AGP Controller (rev 03)
00:1d.0 USB Controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #1 (rev 01)
00:1d.1 USB Controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #2 (rev 01)
00:1d.2 USB Controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #3 (rev 01)
00:1d.7 USB Controller: Intel Corporation 82801DB/DBM (ICH4/ICH4-M) USB2 EHCI Controller (rev 01)
00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev 81)
00:1f.0 ISA bridge: Intel Corporation 82801DBM (ICH4-M) LPC Interface Bridge (rev 01)
00:1f.1 IDE interface: Intel Corporation 82801DBM (ICH4-M) IDE Controller (rev 01)
00:1f.3 SMBus: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) SMBus Controller (rev 01)
00:1f.5 Multimedia audio controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) AC'97 Audio Controller (rev 01)
00:1f.6 Modem: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) AC'97 Modem Controller (rev 01)
01:00.0 VGA compatible controller: ATI Technologies Inc RV350 [Mobility Radeon 9600 M10]
02:00.0 CardBus bridge: Texas Instruments PCI4520 PC card Cardbus Controller (rev 01)
02:00.1 CardBus bridge: Texas Instruments PCI4520 PC card Cardbus Controller (rev 01)
02:01.0 Ethernet controller: Intel Corporation 82540EP Gigabit Ethernet Controller (Mobile) (rev 03)
02:02.0 Network controller: Intel Corporation PRO/Wireless 2200BG Network Connection (rev 05)

----

~ $ cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 13
model name : Intel(R) Pentium(R) M processor 1.80GHz
stepping : 6
cpu MHz : 600.000
cache size : 2048 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 2
wp : yes
flags : fpu vme de pse tsc msr mce cx8 sep mtrr pge mca cmov pat clflush dts acpi mmx fxsr sse sse2 ss tm pbe up est tm2
bogomips : 1200.12

-------

dmesg is attached as a file.

-------

(tdn@bart) (07-05-02 16:52) (P:0 L:1) [0] [ 16:52:05 up 19 days, 16:03, 2 users, load average: 0.21, 0.30, 0.58]
~ $ free
             total used free shared buffers cached
Mem: 1035092 943248 91844 0 14976 238816
-/+ buffers/cache: 689456 345636
Swap: 2344568 1698592 645976
(tdn@bart) (07-05-02 16:52) (P:0 L:1) [0] [ 16:52:15 up 19 days, 16:03, 2 users, load average: 0.18, 0.29, 0.57]
~ $ df -h
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/root 38G 31G 7.2G 81% /
varrun 506M 236K 506M 1% /var/run
varlock 506M 0 506M 0% /var/lock
procbususb 10M 128K 9.9M 2% /proc/bus/usb
udev ...

[tdn (spam-thomasdamgaard)]

Added a list of ps faux from right after the crash:

[tdn (spam-thomasdamgaard)]

Some logging:

(tdn@bart) (07-05-02 16:54) (P:0 L:1) [0] [ 16:54:30 up 19 days, 16:05, 2 users, load average: 0.14, 0.23, 0.51]
~ $ sudo tail -n 30 /var/log/everything/current
May 2 13:17:01 [CRON] (pam_unix) session closed for user root
May 2 13:52:37 [sudo] tdn : TTY=pts/1 ; PWD=/home/tdn ; USER=root ; COMMAND=/usr/bin/nmap -A -T5 mobilenation.dk
May 2 14:15:01 [CRON] (pam_unix) session opened for user tdn by (uid=0)
May 2 14:15:01 [/USR/SBIN/CRON] (tdn) CMD (/home/tdn/bin/hit-12send.dk > /dev/null)
May 2 14:15:02 [CRON] (pam_unix) session closed for user tdn
May 2 14:17:01 [CRON] (pam_unix) session opened for user root by (uid=0)
May 2 14:17:01 [/USR/SBIN/CRON] (root) CMD ( run-parts --report /etc/cron.hourly)
May 2 14:17:01 [CRON] (pam_unix) session closed for user root
May 2 14:58:02 [postfix/master] terminating on signal 15
May 2 15:02:01 [CRON] (pam_unix) session opened for user root by (uid=0)
May 2 15:02:02 [/USR/SBIN/CRON] (root) CMD (if [ -x /usr/sbin/pg_maintenance ]; then /usr/sbin/pg_maintenance --analyze >/dev/null; fi)
May 2 15:02:03 [CRON] (pam_unix) session closed for user root
May 2 15:15:01 [CRON] (pam_unix) session opened for user tdn by (uid=0)
May 2 15:15:01 [/USR/SBIN/CRON] (tdn) CMD (/home/tdn/bin/hit-12send.dk > /dev/null)
May 2 15:15:18 [CRON] (pam_unix) session closed for user tdn
May 2 15:17:01 [CRON] (pam_unix) session opened for user root by (uid=0)
May 2 15:17:01 [/USR/SBIN/CRON] (root) CMD ( run-parts --report /etc/cron.hourly)
May 2 15:17:01 [CRON] (pam_unix) session closed for user root
May 2 15:31:43 [gconfd (tdn-5895)] SIGHUP received, reloading all databases
May 2 15:31:43 [gconfd (tdn-5895)] Resolved address "xml:readonly:/etc/gconf/gconf.xml.mandatory" to a read-only configuration source at position 0
May 2 15:31:43 [gconfd (tdn-5895)] Resolved address "xml:readwrite:/home/tdn/.gconf" to a writable configuration source at position 1
May 2 15:31:43 [gconfd (tdn-5895)] Resolved address "xml:readonly:/etc/gconf/gconf.xml.defaults" to a read-only configuration source at position 2
May 2 15:31:43 [gconfd (tdn-5895)] Resolved address "xml:readonly:/var/lib/gconf/debian.defaults" to a read-only configuration source at position 3
May 2 15:31:43 [gconfd (tdn-5895)] Resolved address "xml:readonly:/var/lib/gconf/defaults" to a read-only configuration source at position 4
May 2 15:32:13 [gconfd (tdn-5895)] SIGHUP received, reloading all databases
May 2 15:32:13 [gconfd (tdn-5895)] Resolved address "xml:readonly:/etc/gconf/gconf.xml.mandatory" to a read-only configuration source at position 0
May 2 15:32:13 [gconfd (tdn-5895)] Resolved address "xml:readwrite:/home/tdn/.gconf" to a writable configuration source at position 1
May 2 15:32:13 [gconfd (tdn-5895)] Resolved address "xml:readonly:/etc/gconf/gconf.xml.defaults" to a read-only configuration source at position 2
May 2 15:32:13 [gconfd (tdn-5895)] Resolved address "xml:readonly:/var/lib/gconf/debian.defaults" to a read-only configuration source at position 3
May 2 15:32:13 [gconfd (tdn-5895)] Resolved address "xml:readonly:/var/lib/gconf/defaults" to a read-only configuration so...

[tdn (spam-thomasdamgaard)]

After rebooting I cannot boot from the first target in GRUB.
I get something about /dev/hda5 not found.
Begin: waiting for root filesystem.
(nothing happens)

Then I selected another target: 2.6.17-11-generic in GRUB. Then I got this what is attached as a picture.

When nothing has happened for a long time, I pressed ctrl+alt+del. And then it continued and after a while I got the KDM login screen.

[tdn (spam-thomasdamgaard)]

My dmesg after the reboot is attached.

[tdn (spam-thomasdamgaard)]

I want to add that much of my customization of KDE has gone!
Some of the short cuts in the panel are gone.
The clock has a wrong appearance.
The System Guard applet in the panel has wrong appearance.

[tdn (spam-thomasdamgaard)]

I just want to add my Ubuntu hardware database entry : 9514b051e60fdb09a10d51200fd2d3c5

[tdn (spam-thomasdamgaard)]

I want to add that my trash can has disappeared.

[Scott Kitterman (kitterman)]

Still getting this on PIII-700 w/256 MB RAM and current Feisty Kubuntu + 3.5.7:

Traceback (most recent call last):
  File "dist-upgrade.py", line 56, in <module>
    app.run()
  File "/home/kitterma/upgrader/DistUpgradeControler.py", line 1255, in run
    self.fullUpgrade()
  File "/home/kitterma/upgrader/DistUpgradeControler.py", line 1237, in fullUpgrade
    if not self.doDistUpgrade():
  File "/home/kitterma/upgrader/DistUpgradeControler.py", line 769, in doDistUpgrade
    res = self.cache.commit(fprogress,iprogress)
  File "/usr/lib/python2.5/site-packages/apt/cache.py", line 203, in commit
    res = self.installArchives(pm, installProgress)
  File "/usr/lib/python2.5/site-packages/apt/cache.py", line 178, in installArchives
    res = installProgress.run(pm)
  File "/usr/lib/python2.5/site-packages/apt/progress.py", line 213, in run
    pid = self.fork()
  File "/home/kitterma/upgrader/DistUpgradeViewKDE.py", line 227, in fork
    self.child_pid = os.fork()
OSError: [Errno 12] Cannot allocate memory

[Mantas Kriaučiūnas (mantas)]

Baltix doesn't use KDE as default

[Scott Kitterman (kitterman)]

$ top | grep python
24518 root 17 0 132m 92m 46m R 3.5 36.9 0:45.67 python
24518 root 17 0 132m 92m 46m D 16.4 37.0 0:46.17 python
24518 root 18 0 750m 156m 23m D 35.1 62.5 0:47.23 python
24518 root 18 0 750m 155m 21m D 4.8 62.0 0:47.40 python
24518 root 18 0 750m 160m 20m D 3.6 64.3 0:47.51 python
24518 root 18 0 750m 165m 12m D 6.3 66.2 0:47.70 python

The jump from 132m to 750m (the size of the swap file on this system) was almost instantaneous when the update-manager transitioned from download packages to starting the upgrade. So the system is truly out of memory it would appear.

[Scott Kitterman (kitterman)]

I think this is a fundamental design problem that is going to take some serious rework if this is going to work on low memory systems. I hunted down were the memory is getting eaten up. It's in DistUpgradeControler.py. I added comments to the procedure below to show the fatal line. The bottom line is that the system is just trying to cache more than a machine with limited memory can hande. Someone who knows more about the what and the why of the cache will have to look and see if it can be slimmed down.

    def doDistUpgrade(self):
        # get the upgrade
        currentRetry = 0
        fprogress = self._view.getFetchProgress()
        iprogress = self._view.getInstallProgress(self.cache)
        # retry the fetching in case of errors
        maxRetries = self.config.getint("Network","MaxRetries")
        while currentRetry < maxRetries:
            try:
                # THIS IS THE FATAL LINE:
                res = self.cache.commit(fprogress,iprogress)
                # THE ONE ABOVE THIS ONE.
            except SystemError, e:
                logging.error("SystemError from cache.commit(): %s" % e)
                # check if the installprogress catched a pkgfailure, if not, generate a fallback here
                if iprogress.pkg_failures == 0:
                    errormsg = "SystemError in cache.commit(): %s" % e
                    apport_pkgfailure("update-manager", errormsg)
                # invoke the frontend now
                msg = _("The upgrade aborts now. Your system "
                        "could be in an unusable state. A recovery "
                        "will run now (dpkg --configure -a).")
                if not run_apport():
                    msg += _("\n\nPlease report this bug against the 'update-manager' "
                             "package and include the files in /var/log/dist-upgrade/ "
                             "in the bugreport.\n"
                             "%s" % e)
                self._view.error(_("Could not install the upgrades"), msg)
                # installing the packages failed, can't be retried
                self._view.getTerminal().call(["dpkg","--configure","-a"])
                self._rewriteAptPeriodic(self.apt_minAge)
                return False
            except IOError, e:
                # fetch failed, will be retried
                logging.error("IOError in cache.commit(): '%s'. Retrying (currentTry: %s)" % (e,currentRetry))
                currentRetry += 1
                continue
            # no exception, so all was fine, we are done
            self._rewriteAptPeriodic(self.apt_minAge)
            return True

[Scott Kitterman (kitterman)]

Upon further investigation, it looks like a python-kde3/konsole issue. See Bug #117731.

[Guillaume Martres (smarter)]

Same problem while trying 'kdesu "adept_manager --dist-upgrade-devel"' (I was already using Gutsy).
I have 512 MB of ram, when the upgrader started to download packages, the system became very slow and all the ram and 500 MB of swap were used.

[mstodd (toaster66)]

*disclaimer: first launchpad posting*

#########
WORKAROUND
#########

It looks like Scott might be right, it's a KDE/qt issue. The way I worked around this during my upgrade from Feisty to Gutsy is the following:

1. Run 'kdesu "adept_manager --version-upgrade"', attempt the upgrade, and allow it to fail.
2. Via a terminal, go to /tmp/kde-root/adept_manager(something).tmp-extract
3. Edit DistUpgrade.cfg so that it only tries to do the upgrade in text mode since python can't load the libs for GTK, and QT has the memory issue
4. Save file
5. Run (as root) dist-upgrade.py

[Ferran Rius (frius64)]

I've tried again today to see if something had changed. I had to power off the computer. I restarted in safe mode and did an "apt-get update && apt-get dist-upgrade" and everything seems to be working fine together.
I think this is a very important issue, as it seems to be affecting quite a lot of people using Kubuntu Gutsy, and 'kdesu "adept_manager --version-upgrade"' is supposed to be the recommended way to upgrade from Feisty to Gutsy.
My opinion as a user is that this bug should be fixed before Gutsy release or, if it's not possible, a workaround for upgrading should be recommended.

[Tzvetan Mikov (tmikov)]

Guys, is there any progress on this bug ? It is extremely serious. It was reported during the upgrade to Feisty, and it looks like it is still present during the upgrade to Gutsy. I was bitten before, when I upgraded a coworker's computer to Feisty (thank god he didn't attempt to do it alone).

I checked the Kubuntu upgrade instructions (http://kubuntu.org/announcements/7.10-release.php#upgrade) and there is no mention of this problem or a workaround. So, is it safe to upgrade ?

[mvsjes2 (robin-robinandmariette)]

I sent in a work around for this, so I don't think it's "extremely
serious", just "extremely annoying". :-) From my recall, the upgrade
had been completed, it was just the cleanup that was not done, and the
workaround allows you to clean up manually.

It is too bad that the bug hasn't been fixed though.

Robin Murray

Tzvetan Mikov wrote:
> Guys, is there any progress on this bug ? It is extremely serious. It
> was reported during the upgrade to Feisty, and it looks like it is still
> present during the upgrade to Gutsy. I was bitten before, when I
> upgraded a coworker's computer to Feisty (thank god he didn't attempt to
> do it alone).
>
> I checked the Kubuntu upgrade instructions
> (http://kubuntu.org/announcements/7.10-release.php#upgrade) and there is
> no mention of this problem or a workaround. So, is it safe to upgrade ?
>

[tdn (spam-thomasdamgaard)]

Workaround or not. I also think that this bug is very serious. It is really too bad that it has not been fixed yet.

[Tzvetan Mikov (tmikov)]

I don't think it is realistic to expect that ordinary users will be able to find this bug and administer a workaround from the command line on their own. At the very least a detailed description of the problem and the workaround should be prominently displayed in the upgrade instructions.

I still keep getting notifications of new people submitting duplicates of this bug when upgrading to Gutsy. Once people lose confidence in the OS, it's very tough trying to restore it.

[Peter Leopold (peter-leopold)]

Does anyone know how to unsubscribe to these notifications?

Tzvetan Mikov wrote:
> I don't think it is realistic to expect that ordinary users will be able
> to find this bug and administer a workaround from the command line on
> their own. At the very least a detailed description of the problem and
> the workaround should be prominently displayed in the upgrade
> instructions.
>
> I still keep getting notifications of new people submitting duplicates
> of this bug when upgrading to Gutsy. Once people lose confidence in the
> OS, it's very tough trying to restore it.
>

--
Peter Leopold, Ph.D.
President
BioAnalyte Inc.
58 Fore St. Bldg 5
Portland, ME 04101
(tel) 207-780-6777 x202
(fax) 207-221-1385
(cel) 207-831-5561
<email address hidden> <http://www.bioanalyte.com>
STATEMENT OF CONFIDENTIALITY
The information contained in this electronic message and any attachments
to this message are intended for the exclusive use of the addressee(s)
and may contain confidential or privileged information. If you are not
the intended recipient, please notify the sender immediately at either
[phone] x202 or at <email address hidden>, and destroy all
copies of this message and any attachments. Thank you for your cooperation.

[Danny Staple (danny-orionrobots)]

Cascokid - follow the links at the bottom of the email notification, and log in to launchpad (use the "remind me" tool if you have forgotten your login). Then in the menu on the top left, there is an "Unsubscribe" button that will do the magic for you.

I will second Tzvetan and say that I view this as a serious defect that may turn people away from Ubuntu and possibly from Linux if that is their user experience. While I would be confident to apply such patches, I say so knowing that I am a software engineer with many years experience coding and using nix variants. To the average user, that simply does not apply, and it will frustrate them. It is worth reading the top of the defect and noting that although in the initial posting it complains about being out memory and the upgrade actually appears to have succeeded, later comments expressed machines no longer booting or failing to connect to the network.

I would go as far as strongly suggesting that the KDE release of Gutsy should not be recommended as an upgrade path from Feisty (or earlier) without a reinstall until this is fixed.

[Danny Staple (danny-orionrobots)]

Missed Something - I also find it a very serious thing that this outstanding issue is not mentioned in the release notes or upgrade guide. This is for some a critical defect, and I would definitely expect a mention of it there.

[djtm (djtm)]

I had the same problem during upgrade to the RC:
I confirmed to remove some packages and pretty much immediately afterwards the update manager(kde) hung up reproducibly.
I have 512 RAM and 768 Swap.
I tried upgrading once more, it crashed at the same spot.

Then I used apt-get dist-upgrade which seemed to pretty much install everything.

But now I still get the message: An upgrade for your system is available.
When I now run the update-manager it tells me it needs to remove packages.
After I confirm this, it tells me that my distribution is already up to date.

But e.g. compiz was not activated or even installed.

My memory error is the following:
----------------------------------------------------------------------------

updateStatus: Systemaktualisierung wird durchgeführt
Error in sys.excepthook:
Traceback (most recent call last):
  File "/tmp/kde-root/adept_managert7pdwb.tmp-extract/DistUpgradeViewKDE.py", line 460, in _handleException
    if not run_apport():
  File "/tmp/kde-root/adept_managert7pdwb.tmp-extract/DistUpgradeApport.py", line 44, in run_apport
    ret = subprocess.call(p)
  File "/usr/lib/python2.5/subprocess.py", line 443, in call
    return Popen(*popenargs, **kwargs).wait()
  File "/usr/lib/python2.5/subprocess.py", line 593, in __init__
    errread, errwrite)
  File "/usr/lib/python2.5/subprocess.py", line 1061, in _execute_child
    self.pid = os.fork()
OSError: [Errno 12] Cannot allocate memory

Original exception was:
Traceback (most recent call last):
  File "/tmp/kde-root/adept_managert7pdwb.tmp-extract/dist-upgrade.py", line 59, in <module>
    app.run()
  File "/tmp/kde-root/adept_managert7pdwb.tmp-extract/DistUpgradeControler.py", line 1346, in run
    self.fullUpgrade()
  File "/tmp/kde-root/adept_managert7pdwb.tmp-extract/DistUpgradeControler.py", line 1328, in fullUpgrade
    if not self.doDistUpgrade():
File "/tmp/kde-root/adept_managert7pdwb.tmp-extract/DistUpgradeControler.py", line 798, in doDistUpgrade
    res = self.cache.commit(fprogress,iprogress)
  File "/tmp/kde-root/adept_managert7pdwb.tmp-extract/DistUpgradeCache.py", line 69, in commit
    apt.Cache.commit(self, fprogress, iprogress)
  File "/usr/lib/python2.5/site-packages/apt/cache.py", line 203, in commit
    res = self.installArchives(pm, installProgress)
  File "/usr/lib/python2.5/site-packages/apt/cache.py", line 178, in installArchives
    res = installProgress.run(pm)
  File "/usr/lib/python2.5/site-packages/apt/progress.py", line 213, in run
    pid = self.fork()
  File "/tmp/kde-root/adept_managert7pdwb.tmp-extract/DistUpgradeViewKDE.py", line 244, in fork
    self.child_pid = os.fork()
OSError: [Errno 12] Cannot allocate memory
updateStatus: Paketverwaltung wird überprüft
X Error: BadDevice, invalid or uninitialized input device 169
  Major opcode: 145
  Minor opcode: 3
  Resource id: 0x0
Failed to open device
X Error: BadDevice, invalid or uninitialized input device 169
  Major opcode: 145
  Minor opcode: 3
  Resource id: 0x0
Failed to open device
adept_manager: Kein Prozess beendet
adept_updater: Kein Prozess beendet

----------------------------------------------------------------------------
and the second time:

updateStat...

[Javier Arántegui (javier-arantegui)]

Hi!

It seems that I am one the clueless users that have been hit by this bug. I even filled a bug report (https://bugs.launchpad.net/ubuntu/+source/update-manager/+bug/154278), that was obviously marked as duplicate.

I wonder what is the best way of action for me. I can think the following actions:

a) Wait until the bug is solved. After reading this thread it doesn't seem that this is going to happen nearly
b) Install the Gnome part of Ubuntu and do the upgrade using the Gnome updater tool
c) Use a more or less cryptic workaround
d) Wait until Kubuntu 8.04
e) Other that I cannot think right now

The truth is that not upgrading the distro is not a big problem for me. In fact I will do it only to get the newest OpenOffice.org (I wish that Ubuntu prepared packets for older distributions to avoid upgrading the distro, but this is another story). What do you suggest me to do?

Thanks,

Javier

[BigPick (wpickard)]

Hello fellow frustrated users.

I also ran into this problem earlier. I have been working on a patch that resolves a major memory leak in the dist-upgrade scripts. Certain raised exceptions are causing infinite loops to occur. Currently, I have only been able to resolve one of these infinite loops, but the memory leak still remains. On the plus side, the upgrade is able to gracefully fail with the current patch and attempt recovery instead of just exiting. I would love to have some of you all test it out and post your resulting logs. It will greatly help diagnose the problem.

For full info see this other bug:
https://bugs.launchpad.net/ubuntu/+source/adept/+bug/154493

[BigPick (wpickard)]

I am pleased to report that using the above patch, my second sandbox tower was finally able to upgrade using the dist-upgrade.py script without error. I will run the test again on my other sandbox tower as soon as I revert it back to a Feisty install. Right now, I need to go to bed.

While this result bodes well, I still need you all to try out the patch and report your results back here. Doing so will greatly aid in the resolution of other errors that still may be lurking. If you need some help applying the patch I posted instructions in the other bug report linked above, just make sure you download the second patch revision instead of the one used in the example. Once you have run the patch, successful or not, please post the log files located in /var/log/dist-upgrade/.

I am not a developer, I am just a lowly peon user who had his install corrupted when the update-manager crashed. As such I need your assistance in getting this patch tested and, if successful, pushed to the higher-ups. Thank you for your help.

[Marco Cimmino (cimmo)]

so the problem is a memory leak, then developers have for sure more details now, well I hope.

[Ferran Rius (frius64)]

BigPick: I'll test your patch as soon I go back home to see if I can confirm your results.
However, I insist on what I (and others) have said. Until a definitive fix for this has been released, this should be considered a critical bug and, as it clearly affects many users, upgrading from Feisty should not be recommended.

[wateenellende (fpbeekhof)]

Agreed. I should add that there are bugs in KDEsu (1), which hamper
the use of adept-updater etc.

Of 5 computers upgraded at home and at work, two were left in a
completely unusable state (one recovered so far), the third is
affected by this memory-bug (2). The fourth and fifth have been
running gutsy for a long time and only required some manual
downloading and installing of .deb files for udev & volumeid, because
this wasn't handled automatically. This was deemed "not a bug" because
I "should have use adept or the upgrade manager", which was obviously
not possble because of bugs (1) and (2).

All in all, I'm NOT impressed: 0 out of 5 upgrades successful. For
now, I recommend against upgrading.

Therefore, creating the patch is very important and I hope it works
out, but for now I'm too busy fixing my unbootable machine to try it.

On 10/25/07, FerranRius <email address hidden> wrote:
> BigPick: I'll test your patch as soon I go back home to see if I can confirm your results.
> However, I insist on what I (and others) have said. Until a definitive fix for this has been released, this should be considered a critical bug and, as it clearly affects many users, upgrading from Feisty should not be recommended.
>
> --
> [MASTER] [kde] Upgrade tool crashed with " Cannot allocate memory" (edgy -> feisty)
> https://bugs.launchpad.net/bugs/107188
> You received this bug notification because you are a direct subscriber
> of a duplicate bug.
>

[BigPick (wpickard)]

Many thanks for the help you guys.

I would also like to thank John and Christian Assig for their efforts so far.

FerranRius's comment is very prudent and correct however, this upgrade should not be attempted whatsoever by anyone who uses their machine for work, school, or other important operations. The patch I posted is simply the fix I came up with for my situation when I attempted to upgrade Feisty on the laptop I use around campus. I never thought I'd be thankful for dual-booting windows, and to be honest, I resent the need to rely on it. Luckily, I have two old towers I use as sandboxes for messing around with networking and various Unix installations. One is an Intel/nVidia, the other is AMD/ATI, both failed the upgrade and became unbootable (so I'm 0 for 3), making them perfect candidates for trying to fix this.

Currently there are two memory leaks occurring as far as I can tell, only one of which I have identified and addressed in the patch. The second appears to be coming from the fetching of backport archives, which occurs prior to the main upgrade. I am unable to replicate this leak on my machines, so I have relied on the work of Christian Assig to track this down. He deserves many thanks for bearing with my sophomoric efforts. Although this patch does not fix the second leak, Christian did report dist-upgrade faied gracefully instead of crashing by bringing up an error window and attempting to recover and reset the system.

I need to repeat that I am not an official developer. I am a user with just enough information to make me dangerous. Nonetheless, I greatly appreciate your efforts to assist me in solving this critical issue.

[Loye Young (loyeyoung)]

What happens if you use "aptitude --full-upgrade" instead of "apt-get
--dist-upgrade" in the script?

On 10/25/07, BigPick <email address hidden> wrote:
>
> Many thanks for the help you guys.
>
> I would also like to thank John and Christian Assig for their efforts so
> far.
>
> FerranRius's comment is very prudent and correct however, this upgrade
> should not be attempted whatsoever by anyone who uses their machine for
> work, school, or other important operations. The patch I posted is
> simply the fix I came up with for my situation when I attempted to
> upgrade Feisty on the laptop I use around campus. I never thought I'd be
> thankful for dual-booting windows, and to be honest, I resent the need
> to rely on it. Luckily, I have two old towers I use as sandboxes for
> messing around with networking and various Unix installations. One is an
> Intel/nVidia, the other is AMD/ATI, both failed the upgrade and became
> unbootable (so I'm 0 for 3), making them perfect candidates for trying
> to fix this.
>
> Currently there are two memory leaks occurring as far as I can tell,
> only one of which I have identified and addressed in the patch. The
> second appears to be coming from the fetching of backport archives,
> which occurs prior to the main upgrade. I am unable to replicate this
> leak on my machines, so I have relied on the work of Christian Assig to
> track this down. He deserves many thanks for bearing with my sophomoric
> efforts. Although this patch does not fix the second leak, Christian did
> report dist-upgrade faied gracefully instead of crashing by bringing up
> an error window and attempting to recover and reset the system.
>
> I need to repeat that I am not an official developer. I am a user with
> just enough information to make me dangerous. Nonetheless, I greatly
> appreciate your efforts to assist me in solving this critical issue.
>
> --
> [MASTER] [kde] Upgrade tool crashed with " Cannot allocate memory" (edgy
> -> feisty)
> https://bugs.launchpad.net/bugs/107188
> You received this bug notification because you are a direct subscriber
> of a duplicate bug.
>

--
Loye Young
Isaac & Young Computer Company
Laredo, Texas
[phone]
<email address hidden>

[hockenberry (hockenberry32)]

i have managed to make the update after all with several apt-get
upgrade commands so i cannot provide this information anymore, sorry
...

On 10/25/07, Loye Young <email address hidden> wrote:
> What happens if you use "aptitude --full-upgrade" instead of "apt-get
> --dist-upgrade" in the script?
>
> On 10/25/07, BigPick <email address hidden> wrote:
> >
> > Many thanks for the help you guys.
> >
> > I would also like to thank John and Christian Assig for their efforts so
> > far.
> >
> > FerranRius's comment is very prudent and correct however, this upgrade
> > should not be attempted whatsoever by anyone who uses their machine for
> > work, school, or other important operations. The patch I posted is
> > simply the fix I came up with for my situation when I attempted to
> > upgrade Feisty on the laptop I use around campus. I never thought I'd be
> > thankful for dual-booting windows, and to be honest, I resent the need
> > to rely on it. Luckily, I have two old towers I use as sandboxes for
> > messing around with networking and various Unix installations. One is an
> > Intel/nVidia, the other is AMD/ATI, both failed the upgrade and became
> > unbootable (so I'm 0 for 3), making them perfect candidates for trying
> > to fix this.
> >
> > Currently there are two memory leaks occurring as far as I can tell,
> > only one of which I have identified and addressed in the patch. The
> > second appears to be coming from the fetching of backport archives,
> > which occurs prior to the main upgrade. I am unable to replicate this
> > leak on my machines, so I have relied on the work of Christian Assig to
> > track this down. He deserves many thanks for bearing with my sophomoric
> > efforts. Although this patch does not fix the second leak, Christian did
> > report dist-upgrade faied gracefully instead of crashing by bringing up
> > an error window and attempting to recover and reset the system.
> >
> > I need to repeat that I am not an official developer. I am a user with
> > just enough information to make me dangerous. Nonetheless, I greatly
> > appreciate your efforts to assist me in solving this critical issue.
> >
> > --
> > [MASTER] [kde] Upgrade tool crashed with " Cannot allocate memory" (edgy
> > -> feisty)
> > https://bugs.launchpad.net/bugs/107188
> > You received this bug notification because you are a direct subscriber
> > of a duplicate bug.
> >
>
>
> --
> Loye Young
> Isaac & Young Computer Company
> Laredo, Texas
> [phone]
> <email address hidden>
>
> --
> [MASTER] [kde] Upgrade tool crashed with " Cannot allocate memory" (edgy -> feisty)
> https://bugs.launchpad.net/bugs/107188
> You received this bug notification because you are a direct subscriber
> of a duplicate bug.
>
>

[BigPick (wpickard)]

All right, I am completely frustrated. First at my inability to fix the second memory leak and second by the total lack of developer input on this issue.

My current working thoery is that commit() function in the Cache class of the python-apt library runs into an infinite loop if an archive install returns a result of "Incomplete". My inability to replicate this error, and lack of familiarity with the python-apt library have thwarted my attempts to fix the problem.

For now, I am just going to post the third revision of my patch, which is essentially a regression. The patch no longer alters the types of Exceptions caught by the programs try/catch statements as this was mainly an attempt at getting more information. This revision just has the single memory leak fix.

I am incredibly displeased and disgusted by this entire situation.

[Marco Cimmino (cimmo)]

yeah BigPick I also had your problem, trying to resolve a big problem and lack of devels.
Unfortunately they have a lot of works and sometimes this a good excuse sometimes not.

anyway try to write an email to the package maintainer <email address hidden> pointing your patches, I'm sure that he wants to resolve this bis issue with so many duplicates :)

[Loye Young (loyeyoung)]

BigPick,

You have been working incredibly hard on this, and I'm sure you are very tired
and frustrated. You have done a great service already. You have already fixed
the biggest issue and gotten the thing back to working much better. Many have
already reported that your patches have enabled them to get their system
upgraded.

Your frustration is evidence of your deep commitment to Ubuntu and to
excellence in everything you do. (And maybe a healthy dose of perfectionism
thrown in as well?) You have many comrades who understand exactly what it
feels like to bang your head against the wall, see the wall move farther than
anyone else has ever done before, and still be pissed off that you can't move
it the rest of the way.

This is open source: it's all volunteer. Don't lose your sanity over it. If
you are tired, take a break. Go do something else. One of three things will
happen: It will still be there when you get back and you will have fresh
perspectives, you will take a second look at it and decide you have better
things to do, or someone will have picked up where you left off. If the
problem is big enough, someone else will jump in to help, just like you did.

St Jude is the patron saint of difficult cases. Perhaps while you are taking
the weekend off, he can go have a talk with the One who programmed us
all. :-)

Happy Trails,

Loye Young

On Friday, October 26, 2007 5:01:06 pm BigPick wrote:
> All right, I am completely frustrated. First at my inability to fix the
> second memory leak and second by the total lack of developer input on
> this issue.
>
> My current working thoery is that commit() function in the Cache class
> of the python-apt library runs into an infinite loop if an archive
> install returns a result of "Incomplete". My inability to replicate this
> error, and lack of familiarity with the python-apt library have thwarted
> my attempts to fix the problem.
>
> For now, I am just going to post the third revision of my patch, which
> is essentially a regression. The patch no longer alters the types of
> Exceptions caught by the programs try/catch statements as this was
> mainly an attempt at getting more information. This revision just has
> the single memory leak fix.
>
> I am incredibly displeased and disgusted by this entire situation.
>
> ** Attachment added: "BigPick dist-upgrade patch rev 3"
>
> http://launchpadlibrarian.net/10180893/gutsy-dist-upgrade_bigpick_0.3.patch

[Javier Arántegui (javier-arantegui)]

Hi!

How are the things going? I'm not a developer and am unable to apply the simplest patch :-(

It's a little bit frustating to be in no men's land. Now my distro is in the middle of the update process so neither I don't get the updates of Kubuntu 7.04 nor I can upgrade :-(

Should I wait until the problem is solved or should I look for greener pastures?

Javier

[Marco Cimmino (cimmo)]

Javier there is a workaround, change the config file and start the update in text mode, this worked around for me.
I've copied into first post steps.

[DJ Brown (speaker2software)]

My solution was simple, Javier:

I'm a Windows tech support geek and I'm making the switch for a lot of
reasons but I have to admit I don’t know Linux like I know Window$ - not
yet anyway. Like you, I don't have the time or the experience to chase down
the problem or do file surgery on an operating system that's new to me. So
I resorted to the nuclear fix - wipe the drive and reinstall.

I had the relevant data backed up but it's just as easy to boot with a
Knoppix CD against the broken machine and back up the data that way. Once
that was done, I reinstalled from the installation CD right over the
original partitions. The install works just fine, it's the upgrade that's
crashing on us. This was true for my upgrade to 7.04 and again to 7.10.

It worked, of course, but it costs time to reconfigure and restore the
backed up data. Next time, maybe, I'll be ready to chase down the answers
but this is an old bug - more than a year old - and it's affected at least
two upgrades to date, so, I figure the developers are either totally
stumped or up to their collective eyeballs in a sea of more important
issues.

Something else you wrote caught my attention, though,

    <<Should I wait until the problem is solved or should I
    look for greener pastures?>>

It's not like Linux folk to sit around on their collective butts. I've
looked around and, for a n00by like myself, Ubuntu is easier to maintain
and I figure it's a good place to learn as well.

Speaker2Software
___________________________________________________
Code & Data: Making Excel Dance since 1994.
   Software Support & Data Services (ETL)
   VBA, COBOL, Documentation & Training
 * P.O. Box 302287; Austin, Texas 78703-2287
___________________________________________________

-----Original Message-----
From: <email address hidden> [mailto:<email address hidden>] On Behalf Of
Javier Arántegui
Sent: Friday, November 02, 2007 7:12 AM
To: <email address hidden>
Subject: [Bug 107188] Re: [MASTER] [kde] Upgrade tool crashed with "
Cannotallocate memory"

Hi!

How are the things going? I'm not a developer and am unable to apply the
simplest patch :-(

It's a little bit frustating to be in no men's land. Now my distro is in
the middle of the update process so neither I don't get the updates of
Kubuntu 7.04 nor I can upgrade :-(

Should I wait until the problem is solved or should I look for greener
pastures?

Javier

--
[Snipped, thank you... Now, me want more cookie...]

[BigPick (wpickard)]

Alright, time for an update on my meddling.

In my earlier investigation into this problem I avoided looking at the python-apt code utilized by the update-manager as this would broaden the scope of the fix to another package. This week, after exhausting all other possible explanations for the second memory leak as reported by Christian Assig and others, I dove in. I identified a possible memory leak in the "commit()" function in "cache.py", and wrote an experimental patch. I will submit this as a new bug against the python-apt package in a moment. Anyone interested in helping resolve this issue, or checking my work, should take a look.

[BigPick (wpickard)]

Bug filed, linky:
https://bugs.launchpad.net/ubuntu/+source/python-apt/+bug/159638

[Tzvetan Mikov (tmikov)]

On Nov 2, 2007 5:12 AM, Javier Arántegui wrote:
> Hi!
>
> How are the things going? I'm not a developer and am unable to apply the
> simplest patch :-(
>
> It's a little bit frustating to be in no men's land. Now my distro is in
> the middle of the update process so neither I don't get the updates of
> Kubuntu 7.04 nor I can upgrade :-(
>
> Should I wait until the problem is solved or should I look for greener
> pastures?

Good luck waiting for a fix ;-) This bug has been known since the
previous release. At that time I was convinced it was going to be
fixed any time now. I would never have imagined that such a serious
upgrade bug would persist for two releases ... To this day there
isn't even a mention of it in the Kubuntu upgrade instructions, let
alone a fix.

This tells me that Canonical simply isn't taking Kubuntu seriously.
They are not to blame - 6-months is way too short time for a robust
release of two different desktops (or even one, if you ask me).
Perhaps another distribution which is primarily KDE-based would be a
better choice (MEPIS ?). Personally, I am posting this from Debian.

Alternatively you could pay $250 for support.

regards,
Tzvetan

[Tzvetan Mikov (tmikov)]

Here is the workaround which worked for me:

* Download the Kubuntu "Alternate Install CD", burn it and mount it in /cdrom
* From a shell execute:
cd $(mktemp -d)
tar xzf /cdrom/dists/gutsy/main/dist-upgrader/binary-all/gutsy.tar.gz
wget http://launchpadlibrarian.net/10255100/DistUpgradeViewText.patch
patch < DistUpgradeViewText.patch
sed -ie "s/View=.*/View=DistUpgradeViewText/" DistUpgrade.cfg
sudo ./gutsy --cdrom /cdrom

The upgrade proceeds in text mode and completes successfully. Ironically there is also a minor bug in the text mode upgrade process (see https://bugs.launchpad.net/ubuntu/+bug/154195) - that is why the patch is necessary.

This is the same workaround as described by cimmo, but hopefully a bit more detailed so a novice could apply it (yeah, right :-).

[Loye Young (loyeyoung)]

On Friday, November 2, 2007 7:12:17 am Javier Arántegui wrote:
> Hi!
>
> How are the things going? I'm not a developer and am unable to apply the
> simplest patch :-(
>
> It's a little bit frustating to be in no men's land. Now my distro is in
> the middle of the update process so neither I don't get the updates of
> Kubuntu 7.04 nor I can upgrade :-(
>
> Should I wait until the problem is solved or should I look for greener
> pastures?
>
> Javier

Help is on the way.

[Michael Vogt (mvo)]

Thanks for the comments on this bugreport and sorry for the trouble this is causing.

@BigPick: Thanks a lot for taking the time to investigate the mater so closely. If you can reproduce the problem reliably I would love to get in touch with you directly so that we can debug it together. If you can reproduce it, could you please tell me what version of kdelibs and kdebase you have installed when the bug happens?

Anyone who can reproduce the issue (maybe inside a virtual machine) and wants to help testing, I would appreciate if you could test the attached patch and see if that makes things better.

Thanks,
 Michael

[BigPick (wpickard)]

OMG its Michael! Thank goodness your here!

Forgive my moronic meddling, I obviously have absolutely no clue what I am doing. I went over my patch again and realized that my changes to the commit retry loops:

- currentRetry = 0
         fprogress = self._view.getFetchProgress()
         iprogress = self._view.getInstallProgress(self.cache)
         # retry the fetching in case of errors
         maxRetries = self.config.getint("Network","MaxRetries")
- while currentRetry < maxRetries:
+ for currentRetry in range(maxRetries):

...
             except IOError, e:
                 # fetch failed, will be retried
                 logging.error("IOError in cache.commit(): '%s'. Retrying (currentTry: %s)" % (e,currentRetry))
- currentRetry += 1

do absolutely nothing. :-D I somehow convinced myself that if an error other than a IOError were thrown, it would be magically caught by the try/catch statement and ignored, resulting in an infinite loop. This is obviously not the case, as erroneous exceptions are immediately passed up to DistUpgradeViewKDE and handled by _handleException. So that wasn't doing anything. No infinite loop. That leaves:

- self[key].markUpgrade()
+ self[key].markInstall()

as the only line which could have made any difference. (And it did for me and a few others for some reason.) What's interesting is that method call is only made in the section of the commit function that checks the state of the main metapackages (kubuntu-desktop, ubuntu-desktop, edubuntu-desktop, etc.). After looking back through my own logs and the logs that others have posted, I noticed that one commonality between some of them was kubuntu-desktop indicated that is wan't installed. In my case, kubuntu-desktop was accidentally removed accidentally by adept a while back when I replaced the ubuntu OO.o packages with ones from a third party repository to fix a font display issue. But this doesn't totally explain everything because the code that reports kubuntu-desktop as not being installed:

 if not metaPkgInstalled():
            logging.debug("none of the '%s' meta-pkgs installed" % metapkgs)
            for key in metapkgs:
                deps_found = True
                for pkg in self.config.getlist(key,"KeyDependencies"):
                    deps_found &= self.has_key(pkg) and self[pkg].isInstalled
                if deps_found:
                    logging.debug("guessing '%s' as missing meta-pkg" % key)
                    try:
                        self[key].markInstall()

occurs after the line that the patch changes. What I do know is that the difference between my failure logs and my success logs is the kubuntu-desktop metapackage being reported as installed in my successful logs right where the error occurs in my failure logs.

So far my only way to reliably test this has been to load Feisty installs onto my two sandbox towers and run them through the update process until they throw the error. Its a crude method of testing though and takes forever. I'm going to reload Feisty again on one of my tower, as both got to Gutsy despite my inept patch attempt, and give your patc...

[Michael Vogt (mvo)]

@BigPick: Thanks for your analysis of the patch, when I read it I was wondering what change in it might have caused that the problem got fixed. My current theory is that the bug occur more or less random (or with a pattern that is very hard to reproduce) so that even if the patch itself has little effect, a upgrade test may still be successful because the bug is not triggered within this run. I'm currently trying to reproduce the problem with the virtualbox package in ubuntu. My current idea of reproducing it is to install kubuntu-feisty and try various combinations of stock kubuntu feisty install, install with updates, with backport enabled etc. Each time a snapshot is taken before the upgrade.

I hope using this method we will be able to find a way to reliable trigger the bug. Everybody is welcome to help with the hunt :) (my main machine is currently not usable, so I'm a bit slower with those tests as I would otherwise). As for the debugging output, I think that strace is usually a good first step. If we could get a gziped strace log when the bug happend, that would be really cool. I suspect the actual problem lies somewhere under the python layer of the code (in the C/C++ bits), so pdb is probably not that helpful. gdb might, once we know a bit better what to look for.

Cheers,
 Michael

[wateenellende (fpbeekhof)]

There are specialized memory debugging tools, for example "valgrind".
If any attempt to allocate memory would fail, I would suspect that
valgrind would be able to give a nice stack trace. (recompile python
without optimization & with debugging symbols!)

refer to http://www.linuxjournal.com/article/6556 for a more detailed
article on the subject.

On 11/6/07, Michael Vogt <email address hidden> wrote:
> @BigPick: Thanks for your analysis of the patch, when I read it I was
> wondering what change in it might have caused that the problem got
> fixed. My current theory is that the bug occur more or less random (or
> with a pattern that is very hard to reproduce) so that even if the patch
> itself has little effect, a upgrade test may still be successful because
> the bug is not triggered within this run. I'm currently trying to
> reproduce the problem with the virtualbox package in ubuntu. My current
> idea of reproducing it is to install kubuntu-feisty and try various
> combinations of stock kubuntu feisty install, install with updates, with
> backport enabled etc. Each time a snapshot is taken before the upgrade.
>
> I hope using this method we will be able to find a way to reliable
> trigger the bug. Everybody is welcome to help with the hunt :) (my main
> machine is currently not usable, so I'm a bit slower with those tests as
> I would otherwise). As for the debugging output, I think that strace is
> usually a good first step. If we could get a gziped strace log when the
> bug happend, that would be really cool. I suspect the actual problem
> lies somewhere under the python layer of the code (in the C/C++ bits),
> so pdb is probably not that helpful. gdb might, once we know a bit
> better what to look for.
>
> Cheers,
> Michael
>
> --
> [patch] Upgrade tool crashed with " Cannot allocate memory"
> https://bugs.launchpad.net/bugs/107188
> You received this bug notification because you are a direct subscriber
> of a duplicate bug.
>

[wateenellende (fpbeekhof)]

Try this:

 valgrind /usr/bin/update-manager

*OUCH*

That's more memory-errors than I can copy-paste!!
Somebody needs to debug python2.5. This is a horrible mess!!

[wateenellende (fpbeekhof)]

For those interested, I tried this:

apt-get install python2.5-dbg valgrind
then, edit your /usr/bin/update-manager, line 1:
#!/usr/bin/python2.5-dbg

Then:
valgrind --log-file=python-errors /usr/bin/update-manager

This produced the attachment, and then said:
Traceback (most recent call last):
  File "/usr/bin/update-manager", line 28, in <module>
    import gtk
  File "/var/lib/python-support/python2.5/gtk-2.0/gtk/__init__.py", line 38, in <module>
    import gobject as _gobject
  File "/var/lib/python-support/python2.5/gtk-2.0/gobject/__init__.py", line 30, in <module>
    from gobject.constants import *
  File "/var/lib/python-support/python2.5/gtk-2.0/gobject/constants.py", line 22, in <module>
    from _gobject import type_from_name
ImportError: /var/lib/python-support/python2.5/gtk-2.0/gobject/_gobject.so: undefined symbol: Py_InitModule4
Error in sys.excepthook:
Traceback (most recent call last):
  File "/var/lib/python-support/python2.5/apport_python_hook.py", line 38, in apport_excepthook
    from apport.fileutils import likely_packaged
  File "/var/lib/python-support/python2.5/apport/__init__.py", line 1, in <module>
    from apport.report import Report
  File "/var/lib/python-support/python2.5/apport/report.py", line 18, in <module>
    from xml.parsers.expat import ExpatError
  File "/usr/lib/python2.5/site-packages/_xmlplus/parsers/expat.py", line 4, in <module>
    from pyexpat import *
ImportError: /usr/lib/python2.5/site-packages/_xmlplus/parsers/pyexpat.so: undefined symbol: Py_InitModule4

Original exception was:
Traceback (most recent call last):
  File "/usr/bin/update-manager", line 28, in <module>
    import gtk
  File "/var/lib/python-support/python2.5/gtk-2.0/gtk/__init__.py", line 38, in <module>
    import gobject as _gobject
  File "/var/lib/python-support/python2.5/gtk-2.0/gobject/__init__.py", line 30, in <module>
    from gobject.constants import *
  File "/var/lib/python-support/python2.5/gtk-2.0/gobject/constants.py", line 22, in <module>
    from _gobject import type_from_name
ImportError: /var/lib/python-support/python2.5/gtk-2.0/gobject/_gobject.so: undefined symbol: Py_InitModule4

I'll see if I can patch things a bit...

[wateenellende (fpbeekhof)]

Sorry, this is a dead end road.

Using the correct suppression file and python-dbg, all errors disappeared (they are false positives) ,
until it crashed because it can't find some gtk lib.
On a second attempt, using the correct suppression file and python without debugging symbols, my system hung hard.
I'm giving up....

[Danny Staple (danny-orionrobots)]

Why was this set to "invalid". The defect still occurs and has been confirmed. No fix for it has yet been released. It may not be against the original packages that we thought, having been traced to a dependency, but it is still an outstanding defect, and the status invalid is not at all appropriate. Provide a fixed updater, and the defect can be closed.

Setting back to confirmed until it has been addressed.

[Marco Cimmino (cimmo)]

why set to invalid?????

[James Westby (james-w)]

Hi,

It's only set to invalid for Baltix, it is still confirmed in
Ubuntu.

Thanks,

James

[Harag (zaries)]

This is happening on a sudo do-release-upgrade from intrepid to jaunty in a virtual machine

Checking for a new ubuntu release
Done Upgrade tool signature
Done Upgrade tools
Done downloading
extracting 'jaunty.tar.gz'
authenticate 'jaunty.tar.gz' against 'jaunty.tar.gz.gpg'

Reading cache

Checking package manager
Reading package lists: Done
Reading state information: Done
Reading state information: Done
Reading state information: Done
Hit http://archive.ubuntu.com intrepid Release.gpg
Hit http://security.ubuntu.com intrepid-security Release.gpg
Hit http://archive.ubuntu.com intrepid Release
Hit http://security.ubuntu.com intrepid-security Release
Done http://archive.ubuntu.com intrepid Release
Done http://security.ubuntu.com intrepid-security Release
Hit http://archive.ubuntu.com intrepid/main Packages
Hit http://security.ubuntu.com intrepid-security/main Packages
Hit http://archive.ubuntu.com intrepid/universe Packages
Hit http://archive.ubuntu.com intrepid/universe Sources
Done downloading
Reading package lists: Done
Reading state information: Done
Reading state information: Done
Reading state information: Done

Updating repository information
Done http://archive.ubuntu.com jaunty Release.gpg
Done http://archive.ubuntu.com jaunty Release
Done http://archive.ubuntu.com jaunty Release
Failed http://security.ubuntu.com jaunty-security Release.gpg
Done http://archive.ubuntu.com jaunty/main Packages
Done http://archive.ubuntu.com jaunty/main Packages
Done http://archive.ubuntu.com jaunty/universe Packages
Done http://archive.ubuntu.com jaunty/universe Packages
Done http://archive.ubuntu.com jaunty/universe Sources
Done http://archive.ubuntu.com jaunty/universe Sources
Done downloading

Checking package manager
Reading package lists: Doneaunty/universe Packages: 98
Reading state information: Done
Reading state information: Done
Reading state information: Done

A fatal error occurred

Please report this as a bug and include the files
/var/log/dist-upgrade/main.log and /var/log/dist-upgrade/apt.log in
your report. The upgrade is now aborted.
Your original sources.list was saved in
/etc/apt/sources.list.distUpgrade.

Traceback (most recent call last):

File "/tmp/tmpoG9RTE/jaunty", line 6, in <module>
main()

File "/tmp/tmpoG9RTE/DistUpgradeMain.py", line 125, in main
app.run()

File "/tmp/tmpoG9RTE/DistUpgradeController.py", line 1575, in run
self.fullUpgrade()

File "/tmp/tmpoG9RTE/DistUpgradeController.py", line 1514, in
fullUpgrade
self.openCache()

File "/tmp/tmpoG9RTE/DistUpgradeController.py", line 164, in
openCache
lock)

File "/tmp/tmpoG9RTE/DistUpgradeCache.py", line 107, in __init__
self.uname =
Popen(["uname","-r"],stdout=PIPE).communicate()[0].strip()

File "/usr/lib/python2.5/subprocess.py", line 594, in __init__
errread, errwrite)

File "/usr/lib/python2.5/subprocess.py", line 1073, in _execute_child
self.pid = os.fork()

OSError: [Errno 12] Cannot allocate memory

[Nikolaus Rath (nikratio)]

The same happens when trying to upgrade from Jaunty to Karmic using do-release-upgrade on a server system without X11.

[Michael Vogt (mvo)]

@Nikolaus Rath: What specs did your system have? How much mem/swap? This error is even earlier than most of the problems described in the report, it fails already when calling "uname -r".

I wonder if for the others:
=== modified file 'DistUpgrade/DistUpgradeController.py'
--- DistUpgrade/DistUpgradeController.py 2009-11-03 16:03:25 +0000
+++ DistUpgrade/DistUpgradeController.py 2009-11-13 13:01:00 +0000
@@ -1040,6 +1040,18 @@
                 logging.error("IOError in cache.commit(): '%s'. Retrying (currentTry: %s)" % (e,currentRetry))
                 currentRetry += 1
                 continue
+ except OSError, e:
+ logging.exception("cache.commit()")
+ # deal gracefully with:
+ # OSError: [Errno 12] Cannot allocate memory
+ if e.errno == 12:
+ self._enableAptCronJob()
+ msg = _("Error during commit")
+ msg += "\n'%s'\n" % str(e)
+ msg += _("Restoring original system state")
+ self._view.error(_("Could not install the upgrades"), msg)
+ # abort() exits cleanly
+ self.abort()
             # no exception, so all was fine, we are done
             self._enableAptCronJob()
             return True

would help mitigating the problem somewhat by at least restoring a clean system state if it happens.

[Nikolaus Rath (nikratio)]

It's a Strato virtual server:

nikratio@ebox:~$ uname -a
Linux ebox 2.6.18-028stab064.7 #1 SMP Wed Aug 26 13:11:07 MSD 2009 i686 GNU/Linux

nikratio@ebox:~$ free
             total used free shared buffers cached
Mem: 5122676 224096 4898580 0 0 0
-/+ buffers/cache: 224096 4898580
Swap: 0 0 0

Do you need anything else?

[Harag (zaries)]

---
Linux dexter.vps 2.6.18-128.2.1.el5.028stab064.7 #1 SMP Wed Aug 26
15:47:17 MSD 2009 i686 GNU/Linux
---
             total used free shared buffers
cached
Mem: 1024000 629444 394556 0 0
0
-/+ buffers/cache: 629444 394556
Swap: 0 0 0

I had a lot more free memory when I tried it because I shut down all my
webservers etc. Currently I have lisp image running that is chewing up
the memory (nearly half).

On Fri, 2009-11-13 at 13:06 +0000, Michael Vogt wrote:
> @Nikolaus Rath: What specs did your system have? How much mem/swap? This
> error is even earlier than most of the problems described in the report,
> it fails already when calling "uname -r".
>
> I wonder if for the others:
> === modified file 'DistUpgrade/DistUpgradeController.py'
> --- DistUpgrade/DistUpgradeController.py 2009-11-03 16:03:25 +0000
> +++ DistUpgrade/DistUpgradeController.py 2009-11-13 13:01:00 +0000
> @@ -1040,6 +1040,18 @@
> logging.error("IOError in cache.commit(): '%s'. Retrying (currentTry: %s)" % (e,currentRetry))
> currentRetry += 1
> continue
> + except OSError, e:
> + logging.exception("cache.commit()")
> + # deal gracefully with:
> + # OSError: [Errno 12] Cannot allocate memory
> + if e.errno == 12:
> + self._enableAptCronJob()
> + msg = _("Error during commit")
> + msg += "\n'%s'\n" % str(e)
> + msg += _("Restoring original system state")
> + self._view.error(_("Could not install the upgrades"), msg)
> + # abort() exits cleanly
> + self.abort()
> # no exception, so all was fine, we are done
> self._enableAptCronJob()
> return True
>
> would help mitigating the problem somewhat by at least restoring a clean
> system state if it happens.
>

[madamos (madamos)]

http://aromasofcoorg.com/default/index.php

--
Political tags - such as royalist, communist, democrat, populist,
fascist, liberal, conservative, and so forth - are never basic
criteria. The human race divides politically into those who want
people to be controlled and those who have no such desire.

[Sebastien Bacher (seb128)]

is that still an issue in karmic or lucid? the bug didn't get new duplicates or comment for months now

[Tzvetan Mikov (tmikov)]

Sebastien, I will be upgrading my laptop from Kubuntu 8.04 to 10.04 one of these days, so I will post back here. Frankly, I am scared to upgrade, but it will be a good test because it is double upgrade from 8.04 to 9.10 and then to 10.04 (Kubuntu doesn't support a direct upgrade).

[Tzvetan Mikov (tmikov)]

Hi,
I just upgraded from Kubuntu 8.04 to 9.10 and then to 10.04 and didn't experience the problem. I used to have this problem on previous upgrades on the exact same system, so it appears it has been fixed. I vote to close it.

[Mohamed Amine Ilidrissi (ilidrissi.amine)]

Invalidating per last comment. Please re-open if you're still affected.