Update Manager never actually updates

Bug #237025 reported by Pete Goodall on 2008-06-03
4
Affects Status Importance Assigned to Milestone
update-manager (Ubuntu)
Undecided
Unassigned

Bug Description

Binary package hint: update-manager

When I click on [ Install Updates ] I am prompted for my password, but then taken directly back to the available updates list. No upgrade occurs and I'm stuck in a loop of clicking [ Install Updates ] and authenticating. Works fine with `sudo aptitude full-upgrade`.

In addition, the screen does not seem to be re-drawing properly. See the attached screenshot. Once I enter my password the password dialog does not go away, but is inactive and the dots replacing the entered characters still appear. Meanwhile the Updates Manager window refreshes the available updates and tells me the same number of updates are still available. The shadow that appears along with the password prompt remains in places where no new window has appeared. If I keep clicking on areas of the screen the shadow disappears in that area.

To be clear, upgrade works with apt-get and aptitude, but not with the Updates Manager.

~$ lsb_release -rd
Description: Ubuntu 8.04
Release: 8.04

~$ apt-cache policy update-manager
update-manager:
  Installed: 1:0.87.27
  Candidate: 1:0.87.27
  Version table:
 *** 1:0.87.27 0
        500 http://gb.archive.ubuntu.com hardy-updates/main Packages
        100 /var/lib/dpkg/status
     1:0.87.24 0
        500 http://gb.archive.ubuntu.com hardy/main Packages

Pete Goodall (pgoodall) wrote :
James Westby (james-w) wrote :

Hi,

Thanks for the bug report.

Are you running compiz? I have seen something like the screenshot
you posted when compiz isn't happy. I think that is tangential to the
real problem though.

update-manager actually uses synaptic to do the upgrade, do you
have any problem running and using synaptic?
(System->Administration->Synaptic Package Manager)

It would be great to have any error message from the failure, it might
just be difficult to find them. Could you please attach your ~/.xsession-errors
from a session in which you had the problem? Do you get any error
messages if you run update-manager from a terminal?

Thanks,

James

Pete Goodall (pgoodall) wrote :

Yes, I am using Compiz. I ran `sudo update-manager` from the command-line and when I click on [ Install Updates ] I get the proper window that shows me what operations it will perform, rather than just being returned to the available updates dialog. I did not run the update, so that I could continue to test. However, I can update one package if you think that is necessary.

I then tried running `gksu update-manager`, but since I just used sudo I did not get a pw prompt. I will wait for the sudo timeout and will try again with gksu, as I'm wondering if it is that pw prompt that might be the problem.

Per your request my ~/.xsession-errors is attached.

On Tue, 2008-06-03 at 11:19 +0000, Pete Goodall wrote:
> Yes, I am using Compiz. I ran `sudo update-manager` from the command-
> line and when I click on [ Install Updates ] I get the proper window
> that shows me what operations it will perform, rather than just being
> returned to the available updates dialog. I did not run the update, so
> that I could continue to test. However, I can update one package if you
> think that is necessary.
>
> I then tried running `gksu update-manager`, but since I just used sudo I
> did not get a pw prompt. I will wait for the sudo timeout and will try
> again with gksu, as I'm wondering if it is that pw prompt that might be
> the problem.
>
> Per your request my ~/.xsession-errors is attached.

Hi,

Thanks for the extra information.

'update-manager' itself doesn't run as root normally, so could
you test running plain 'update-manager' from a terminal?

Your ~/.xsession-errors doesn't have anything obviously related,
so I haven't got any more suggestions to give from that.

Thanks,

James

Michael Vogt (mvo) wrote :

Thanks for your bugreport.

This sounds like a issue with gksu. Could you please open a terminal and run:
$ gksu id
and tell me what output that gives you?

Could you also please run "locale" and let me know what that outputs?

Changed in update-manager:
status: New → Incomplete
Pete Goodall (pgoodall) wrote :

~$ gksu id

~$
~$

Essentially returns nothing. :-/

~$ locale
LANG=en_US.UTF-8
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_PAPER="en_US.UTF-8"
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT="en_US.UTF-8"
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=

Let me know if you need additional information. Btw, I ran update-manger from the command line as a regular user and don't get any particularly interesting output. Don't think ~/.xsession-errors is interesting either, but let me know if you want me to attach it.

Michael Vogt (mvo) wrote :

This might be a duplicate of the gksu problem in ug #237325

Pete Goodall (pgoodall) wrote :

Hmm.... How so? There is no problem resolving the hostname and there is no hang. Just no action. :-/

pete@rhesus:~$ ping -c4 localhost
PING localhost (127.0.0.1) 56(84) bytes of data.
64 bytes from localhost (127.0.0.1): icmp_seq=1 ttl=64 time=0.074 ms
64 bytes from localhost (127.0.0.1): icmp_seq=2 ttl=64 time=0.069 ms
64 bytes from localhost (127.0.0.1): icmp_seq=3 ttl=64 time=0.071 ms
64 bytes from localhost (127.0.0.1): icmp_seq=4 ttl=64 time=0.075 ms

--- localhost ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 2998ms
rtt min/avg/max/mdev = 0.069/0.072/0.075/0.006 ms
pete@rhesus:~$ ping -c4 rhesus
PING rhesus (127.0.1.1) 56(84) bytes of data.
64 bytes from rhesus (127.0.1.1): icmp_seq=1 ttl=64 time=0.075 ms
64 bytes from rhesus (127.0.1.1): icmp_seq=2 ttl=64 time=0.043 ms
64 bytes from rhesus (127.0.1.1): icmp_seq=3 ttl=64 time=0.070 ms

--- rhesus ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 1999ms
rtt min/avg/max/mdev = 0.043/0.062/0.075/0.016 ms
pete@rhesus:~$ ping -c4 rhesus.local
PING rhesus.local (192.168.122.1) 56(84) bytes of data.
64 bytes from rhesus.local (192.168.122.1): icmp_seq=1 ttl=64 time=0.030 ms
64 bytes from rhesus.local (192.168.122.1): icmp_seq=2 ttl=64 time=0.062 ms
64 bytes from rhesus.local (192.168.122.1): icmp_seq=3 ttl=64 time=0.061 ms
64 bytes from rhesus.local (192.168.122.1): icmp_seq=4 ttl=64 time=0.061 ms

--- rhesus.local ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3003ms
rtt min/avg/max/mdev = 0.030/0.053/0.062/0.015 ms

Pete Goodall (pgoodall) wrote :

OK. Well this definitely is not a problem with update-manager. This is a problem with libthinkfinger (or maybe libpam-libthinkfinger). I configured my system to use libthinkfinger and libpam-thinkfinger. If I authenticate with the integrated fingerprint reader it works fine. If I use a password the behaviour is as described above. If I use aptitude and use my password to authenticate. It is asking me for a password twice. Something is screwy here. I'll close this as invalid.

Changed in update-manager:
status: Incomplete → Invalid
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers