Upgrade from gutsy to hardy hangs

[kumaresan]

I tried to upgrade from gutsy to hardy-beta (using update-manager -d and also through alternate-cd)

In both cases, it hangs in first phase(preparing to install).
The status shows "checking package manager".

Few debug info:

$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 7.10
Release: 7.10
Codename: gutsy

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

2008-03-23 00:09:06,460 INFO release-upgrader version '0.87.12' started
2008-03-23 00:09:07,002 DEBUG Using 'DistUpgradeViewGtk' view
2008-03-23 00:09:07,159 DEBUG lsb-release: 'gutsy'
2008-03-23 00:09:07,159 DEBUG _pythonSymlinkCheck run
2008-03-23 00:09:08,794 DEBUG checkViewDepends()

$ sudo apport-cli -f -P 9540

*** Collecting problem information

The collected information can be send to the developers to improve the
application. This might take a few minutes.
Traceback (most recent call last):
  File "/usr/bin/apport-cli", line 282, in <module>
    app.run_argv()
  File "/var/lib/python-support/python2.5/apport/ui.py", line 253, in run_argv
    self.run_report_bug()
  File "/var/lib/python-support/python2.5/apport/ui.py", line 237, in run_report_bug
    self.collect_info()
  File "/var/lib/python-support/python2.5/apport/ui.py", line 348, in collect_info
    icthread.exc_raise()
  File "/var/lib/python-support/python2.5/apport/REThread.py", line 37, in run
    self._retval = self.__target(*self.__args, **self.__kwargs)
  File "/var/lib/python-support/python2.5/apport/ui.py", line 38, in thread_collect_info
    report.add_hooks_info()
  File "/var/lib/python-support/python2.5/apport/report.py", line 499, in add_hooks_info
    assert self.has_key('Package')
AssertionError

UPDATE: This also happens to normal hardy (bug is a little old).

[Richard Lithvall (rich-ubuntu)]

I get the exact same behaviour:

$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 7.10
Release: 7.10
Codename: gutsy

$ cat /var/log/dist-upgrade/main.log
2008-04-18 08:20:23,904 INFO release-upgrader version '0.87.18' started
2008-04-18 08:20:28,656 DEBUG Using 'DistUpgradeViewGtk' view
2008-04-18 08:20:28,835 DEBUG lsb-release: 'gutsy'
2008-04-18 08:20:28,836 DEBUG _pythonSymlinkCheck run
2008-04-18 08:20:30,123 DEBUG checkViewDepends()

$ sudo apport-cli -f -P 7314

*** Collecting problem information

The collected information can be send to the developers to improve the
application. This might take a few minutes.
Traceback (most recent call last):
  File "/usr/bin/apport-cli", line 282, in <module>
    app.run_argv()
  File "/var/lib/python-support/python2.5/apport/ui.py", line 253, in run_argv
    self.run_report_bug()
  File "/var/lib/python-support/python2.5/apport/ui.py", line 237, in run_report_bug
    self.collect_info()
  File "/var/lib/python-support/python2.5/apport/ui.py", line 348, in collect_info
    icthread.exc_raise()
  File "/var/lib/python-support/python2.5/apport/REThread.py", line 37, in run
    self._retval = self.__target(*self.__args, **self.__kwargs)
  File "/var/lib/python-support/python2.5/apport/ui.py", line 38, in thread_collect_info
    report.add_hooks_info()
  File "/var/lib/python-support/python2.5/apport/report.py", line 499, in add_hooks_info
    assert self.has_key('Package')
AssertionError

[Thinboy00 (thinboy00)]

Not that anyone cares, but I can vouch that the above screenshot is real, it has happened to me. Of course, I'm not exactly an established member of the community, so no one cares about my vouching. Force quit on the window works, but leaves a background process. "End process" on the process, whose name is conveniently "hardy," does work. The problem is that "hardy" doesn't. I've tried this both from the cd using gmount-iso (gnome baker choked and trashed a cd), and directly from the upgrade manager. Neither works.

[Thinboy00 (thinboy00)]

The real problem is that this is still happening even though it's not beta anymore!

[Thinboy00 (thinboy00)]

I tried
$ gksudo "update-manager --dist-upgrade"

see screenshot for quite interesting results

[Thinboy00 (thinboy00)]

I made a rather choppy video with Istanbul Desktop Session Recorder.

[Thinboy00 (thinboy00)]

Just installed an update to update-manager and update-manager-core. It didn't help

[Thinboy00 (thinboy00)]

my video is now of the correct MIME type. Unfortunately, mozplugger needs to be modified to work it properly (for some bizarre reason, it didn't support video/x-theora+ogg). If you have it, try
~$ man mozplugger
to see how to modify it. Obviously, this is quite offtopic and is not a workaround for this bug.

[Thinboy00 (thinboy00)]

I'm considering marking this as a security vulnerability per the following reasoning:
1) There are probably security vulnerabilities in Gusty that are fixed in Hardy.
2) This bug is barring fixes of those /known/ security vulnerabilities.
3) This bug is a security vulnerability, or directly causes /at least/ one.
If there are no logical objections in the next twelve hours, I will go ahead and do so.

[Thinboy00 (thinboy00)]

I have gone ahead and marked it, much later than I thought I would.

[Travis Watkins (amaranth)]

Known vulnerabilities are fixed in gutsy too so not being able to upgrade to hardy is not a security problem.

[Thinboy00 (thinboy00)]

So are we going to wait until Gusty is no longer supported and they're no longer supplied?

[Thinboy00 (thinboy00)]

I located the /tmp subdirectory in which hardy's upgrade lies. I did the following
$ gksudo "python -dv hardy" 2>[name of debug file]
I then added a few short headers/footers to the debug file to indicate its contents. I did my best to make it very clear where the headers end and the debug contents begin. Edited file is attached. The actual contents were not edited, only wrapped in headers/footer.

[Thinboy00 (thinboy00)]

When running gksudo python hardy, I get the same behavior I would have gotten had I done it the traditional, GUI way. On the other hand, running just gksudo hardy exits almost immediately. On the gripping hand, when done the traditional way, it appears to be executed (by root) simply as hardy. This means the environment (files etc.) needs to be in a special state for hardy to function.

[Thinboy00 (thinboy00)]

Regarding my most recent attachment (hardy stderr contents):
$ md5sum hardy_err_unedited
7d9a82770bc35ae071d85b16320c8037 hardy_err_unedited

where hardy_err_unedited is the name of the file sans headers. Can anyone else confirm the same contents (using an md5sum and the appropriate commands to reproduce the debug data as shown above)?

To locate the /tmp subdir:
1. Run the upgrader again via GUI. Kill it when it crashes.
2. Open a terminal and:
3. cd /tmp
4. ls -lt | head
5. find the first item that is a directory and starts with "tmp" Its format is tmp[several random uppercase(?) letters].
6. cd [directory from previous step]
7. you are now in the appropriate directory.

[Thinboy00 (thinboy00)]

I removed the "beta" from the title, because it happens to the regular hardy as well.

[Thinboy00 (thinboy00)]

WORKAROUND:
Log into a failsafe terminal and type gksudo update-manager
From there, it's self explanatory.

[Jean-Baptiste Lallement (jibel)]

Thank you for taking the time to report this bug and helping to make Ubuntu better. You reported this bug a while ago and there hasn't been any activity in it recently. We were wondering is this still an issue for you? Can you try with latest Ubuntu release? Thanks in advance.

[Philippe (philippe-faure)]

I am trying to upgrade from 8.04 to 8.10.

lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 8.04.1
Release: 8.04
Codename: hardy

sudo do-release-upgrade
Checking for a new ubuntu release
Done Upgrade tool signature
Done Upgrade tool
Done downloading
extracting 'intrepid.tar.gz'
Traceback (most recent call last):
  File "/usr/bin/do-release-upgrade", line 53, in <module>
    fetcher.run()
  File "/usr/lib/python2.5/site-packages/UpdateManager/Core/DistUpgradeFetcherCore.py", line 202, in run
    if not self.extractDistUpgrader():
  File "/usr/lib/python2.5/site-packages/UpdateManager/Core/DistUpgradeFetcherCore.py", line 129, in extractDistUpgrader
    tar = tarfile.open(self.tmpdir+"/"+os.path.basename(self.uri),"r")
  File "/usr/lib/python2.5/tarfile.py", line 1153, in open
    raise ReadError("file could not be opened successfully")
tarfile.ReadError: file could not be opened successfully

then the upgrade dies.

[Michele Mangili (mangilimic)]

Hello, Philippe!

Your problem doesn't seem related to this bug report. So I suggest you should file a new report to describe your problem!

In the meantime I'm going to mark this report as "Invalid" because it lacks the information we need to investigate the problem, as described in the previous comments. Please reopen it if you can give us the missing information, and don't hesitate to submit bug reports in the future. To reopen the bug report you can click on the current status, under the Status column, and change the Status back to "New". Thanks again!

[Philippe (philippe-faure)]

thank you Michele,

I am not sure of waht the problem was, but it has now worked and I can
not provide you anymore detail. Close this issue.

Philippe

Quoting Michele Mangili <email address hidden>:

> Hello, Philippe!
>
> Your problem doesn't seem related to this bug report. So I suggest you
> should file a new report to describe your problem!
>
> In the meantime I'm going to mark this report as "Invalid" because it
> lacks the information we need to investigate the problem, as described
> in the previous comments. Please reopen it if you can give us the
> missing information, and don't hesitate to submit bug reports in the
> future. To reopen the bug report you can click on the current status,
> under the Status column, and change the Status back to "New". Thanks
> again!
>
> ** Changed in: update-manager (Ubuntu)
> Status: Incomplete => Invalid
>
> --
> Upgrade from gutsy to hardy hangs
> https://bugs.launchpad.net/bugs/205225
> You received this bug notification because you are a direct subscriber
> of the bug.
>