Getting upgrade prerequisites for system upgrade failed

Thanks for your bugreport.

This is fixed in my bzr branch and I will do a upload with the fixed update-manager to hardy-proposed.

This is not relevant for intrepid (closing the intrepid task therefore) only for hardy.

Here is the relevant diff:

=== modified file 'DistUpgrade/DistUpgrade.cfg.dapper'
--- DistUpgrade/DistUpgrade.cfg.dapper 2008-06-20 17:57:39 +0000
+++ DistUpgrade/DistUpgrade.cfg.dapper 2008-06-24 20:10:21 +0000
@@ -43,7 +43,6 @@
 SourcesList=prerequists-sources.dapper.list
 SourcesList-ia64=prerequists-sources.dapper-ports.list
 SourcesList-hppa=prerequists-sources.dapper-ports.list
-SourcesList-sparc=prerequists-sources.dapper-ports.list

 [Sources]
 From=dapper

=== modified file 'debian/changelog'
--- debian/changelog 2008-06-20 17:57:39 +0000
+++ debian/changelog 2008-06-24 20:15:42 +0000
@@ -1,3 +1,9 @@
+update-manager (1:0.87.29) hardy-proposed; urgency=low
+
+ * fix sparc upgrades prerequisites fetching (LP: #239458)
+
+ -- Michael Vogt <email address hidden> Tue, 24 Jun 2008 22:10:03 +0200
+
 update-manager (1:0.87.28) hardy-proposed; urgency=low

   * DistUpgrade/mirrors.cfg:

As a workaround you can run:
$ find /tmp -name "DistUpgrade.cfg.dapper"
then cd into that dir, apply the patch manually and run
$ sudo ./dist-upgrade --mode=server

Accepted into -proposed, please test and give feedback here. Please see https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

Copied to hardy-updates. It has been verified that the new update-manager can successfully upgrade 7.10 to 8.04 without noticeable regressions. Unfortunately it could not be verified from a third party that this bug is really fixed, but we strongly believe it is. If you still have problems, please report back here. Thank you!

According to the recent duplicate ( bug 303926 ) the upgrade from dapper to hardy on Sparc is still failing.

Heurm - I tried the various workarounds listed above but none of them did the trick on my dapper sparc. Also I can't upgrade my gutsy sparc to hardy either -- I'll post logs for the gutsy upgrade to this ticket when I get a chance.

I looked into ths today and it turns out the bug is really that pyhton-apt in hardy-updates calls apt_pkg.init() at the wrong point. So both a new python-apt and a rebuild of update-manager will be required.

Accepted python-apt into hardy-proposed, please test and give feedback here. Please see https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

Accepted update-manager into hardy-proposed, please test and give feedback here. Please see https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

Hi Martin,

It seems to work going from gutsy --> hardy on sparc

I'll let you know for dapper --> hardy

Thanks!!
Robert

Martin Pitt wrote:
> Accepted python-apt into hardy-proposed, please test and give feedback
> here. Please see https://wiki.ubuntu.com/Testing/EnableProposed for
> documentation how to enable and use -proposed. Thank you in advance!
>
> ** Changed in: python-apt (Ubuntu Hardy)
> Status: In Progress => Fix Committed
>
> ** Tags added: verification-needed
>
> ** Changed in: update-manager (Ubuntu Hardy)
> Status: In Progress => Fix Committed
>
>

testing with --proposed on a sparc64 dapper machine it is now able to upgrade the machine.

Works; but only when the ubuntu-desktop metapackage is removed;
otherwise unresolvable dependency problems seem to occur

Chris Jones wrote:
> testing with --proposed on a sparc64 dapper machine it is now able to
> upgrade the machine.
>
>

Hello g-rob,

g-rob [2009-01-30 13:12 -0000]:
> Works; but only when the ubuntu-desktop metapackage is removed;
> otherwise unresolvable dependency problems seem to occur

Can you be more specific, please?

Thanks, Martin
--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)

Hi Martin,

I removed xvnc-viewer, which triggered the removal of the ubuntu-desktop
package. After that the upgrade was able to proceed BUT the server
didn't come up after reboot - it freezes at "booting linux..." - looking
around seems to be a problem with the swap partition - anyway that is a
seperate issue.

Martin Pitt wrote:
> Hello g-rob,
>
> g-rob [2009-01-30 13:12 -0000]:
>
>> Works; but only when the ubuntu-desktop metapackage is removed;
>> otherwise unresolvable dependency problems seem to occur
>>
>
> Can you be more specific, please?
>
> Thanks, Martin
>

Hi, I have a Sun E420R running gutsy and as is it approaching EOL, I would like to upgrade it to hardy so I can get LTS support. However, I did attempt this once and it had disastrous results. It would seem the upgrade took, but upon rebooting the server, about half way through the startup, the console started to display garbled characters, couldn't even SSH to it and rendered it useless. I ended up having to re-install gutsy and restore the server from backups. I would really enjoy doing an upgrade and have it work like it should, thus I have been scared to make any attempt at it again. I guess my question is, has there been any luck with doing a successful upgrade from gutsy to hardy on sparc64 arch? As I stated before, I (and I am sure many others) would like to upgrade before gutsy goes EOL, but would like to do so with confidence it will work as it should. Thanks.

It worked ok for me on a Sun V100 ...but I tried to upgrade a sparc
clone and it didn't work at all - it upgraded...and then it wouldn't boot

Luke J Militello wrote:
> Hi, I have a Sun E420R running gutsy and as is it approaching EOL, I
> would like to upgrade it to hardy so I can get LTS support. However, I
> did attempt this once and it had disastrous results. It would seem the
> upgrade took, but upon rebooting the server, about half way through the
> startup, the console started to display garbled characters, couldn't
> even SSH to it and rendered it useless. I ended up having to re-install
> gutsy and restore the server from backups. I would really enjoy doing
> an upgrade and have it work like it should, thus I have been scared to
> make any attempt at it again. I guess my question is, has there been
> any luck with doing a successful upgrade from gutsy to hardy on sparc64
> arch? As I stated before, I (and I am sure many others) would like to
> upgrade before gutsy goes EOL, but would like to do so with confidence
> it will work as it should. Thanks.
>
>

That sounds exactly what my server did. I really wish sparc was still mainstream supported. I can see why you would do away with ppc, but a lot of old sun sparc gear is still very useful ;) Guess I will wait until the EOL day and upgrade then and see what happens.

I have a Sun Ultra E2 that I can use as a test system. I will install Gutsy, update it, setup a few services and then attempt to upgrade it to Hardy and see how it goes. I will report my findings here once completed.

Well I have successfully updated to Hardy on sparc architecture. Had a few issues that were somewhat easily solvable. First, I could not get a virgin install of Gutsy to install (I figured out why later). So I installed a virgin install of Feisty. I then upgraded to Gutsy at which time I could not get kernel 2.6.22 to boot properly (was getting a UUID error). Thus I booted with kernel 2.6.20 and the system came up installed with Gutsy. I swapped the 'UUID' parameters for old style '/dev/foo/bar' and that got me to the point where the kernel was not loading the correct modules. Here is what was going on (also why a virgin Gutsy install would not work). Through some extensive research, it would appear the developer who wrote the 'esp' module for the kernel trashed it and re-wrote it as 'sun_esp' in kernel 2.6.22, which now depends on 'esp_scsi'. This seemed like and easy fix, just add it to '/etc/modules', however this did not work and I could only assume this was because of an order of operations. Since the module in question was the SCSI bus, the kernel could not read the drives and thus could not read '/etc/modules'. After a short timeout during the kernel load, once it dropped to a shell, I could issue 'modprobe esp_scsi' and 'modprobe sun_esp' and the system would come up. This was the workaround I came up with...

[root@Lazarus ~]# echo esp_scsi >> /etc/initramfs-tools/modules
[root@Lazarus ~]# echo sun_esp >> /etc/initramfs-tools/modules
[root@Lazarus ~]# update-initramfs -k all -u

This made the system boot up and become stable, however reverting back to the 'UUID' format rendered the system un-bootable again. So I left it with the '/dev/foo/bar' format and proceeded to upgrade to Hardy. Once Hardy was installed along with kernel 2.6.24, I was able to get the system to boot with the 'UUID' format w/ my workaround for the SCSI modules. In the end I believe the root cause was hw-detect not seeing the ESP SCSI bus and/or the new modules that needed to be installed to the kernel. Hardy works fine now with the workaround and kernel 2.6.24, however with the 'UUID' problem in kernel 2.6.22, I believe 2.6.22 to be a bad kernel choice for the sparc architecture. Although, if one was to recompile it, it may work.

This bug was fixed in the package python-apt - 0.7.4ubuntu7.5

---------------
python-apt (0.7.4ubuntu7.5) hardy-proposed; urgency=low

  * aptsources/__init__.py, aptsources/distinfo.py:
    - run apt_pkg.init() when aptsources gets imported and not
      the distinfo function (LP: #239458)

 -- Michael Vogt <email address hidden> Tue, 27 Jan 2009 11:45:44 +0100

This bug was fixed in the package update-manager - 1:0.87.31

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

  * no changes upload with a current version from python-apt
    to fix sparc upgrades from dapper to hardy (LP: #239458)

 -- Michael Vogt <email address hidden> Tue, 27 Jan 2009 11:04:22 +0100