"Install Updates" button does nothing when Update Manager opened by itself

@mvo, this should probably be SRU'd into karmic?

I can confirm this on two separate machines, one is a clean karmic install and one is an upgraded machine. For me, it only happens if you let update-manager open by itself (the way it does after two weeks or whatever). When I explicitly click System::Administration::UpdateManager the install button works as expected.

I believe that when update manager is launched implicitly (i.e. when it automatic opens at startup if not used for two weeks when there is updates available) then the code inside the "install" button that handles privilege escalation fails somehow. It fails to even get to the point where the root password prompt is engaged.

I find nothing in dmesg after this happened but there is an interesting error message printed into ~/.xsession-errors:

** (update-notifier:1691): DEBUG: --security-updates-unattended: 0
Window manager warning: Buggy client sent a _NET_ACTIVE_WINDOW message with a timestamp of 0 for 0x4200027 (Update Man)
Window manager warning: meta_window_activate called by a pager with a 0 timestamp; the pager needs to be fixed.
Traceback (most recent call last):
  File "/usr/lib/python2.6/dist-packages/UpdateManager/UpdateManager.py", line 581, in on_button_install_clicked
    self.cache.checkFreeSpace()
  File "/usr/lib/python2.6/dist-packages/DistUpgrade/DistUpgradeCache.py", line 1051, in checkFreeSpace
    for (dir, size) in [(archivedir, self.requiredDownload),
  File "/usr/lib/python2.6/dist-packages/UpdateManager/Core/MyCache.py", line 72, in requiredDownload
    pm.GetArchives(fetcher, self._list, self._records)

This is more than a minor annoyance. Why have update-manager popup if the program is then unusable?
I personally liked the old update notification method better but am trying to get used to the popup.
However this type of problem makes ubuntu look very bad since it has been 5 months without a fix.
I have 4 machines in the house with ubuntu. All have this bug.

I can't reproduce this in Karmic neither with 1:0.126.6 or 1:0.126.9 . When update-notifier popup update-manager the install button is enabled and when I click on it, the password dialog pops up.

This is probably related to the following message in Martin's log
SystemError: E:I wasn't able to locate file for the xulrunner-1.9.1-gnome-support package. This might mean you need to manually fix this package.

Could anyone reproducing this issue attach his ~/.xsession-errors file ?

BTW if you're able to reproduce it, could you please attach the file /var/log/dpkg/status to this report ? Thanks.

Jean-Baptiste Lallement wrote:
> I can't reproduce this in Karmic neither with 1:0.126.6 or 1:0.126.9 .
>

I've just had this happen with 1:0.126.9.

> BTW if you're able to reproduce it, could you please attach the file
>
> /var/log/dpkg/status to this report ? Thanks.

Attached.

Thanks,

Michael

Several of the duplicate bug reports have an xsession-errors file. What's "Invalid" about this bug?

For what it is worth I also see this bug often. I am using a local Ubuntu mirror that syncs once per day in the early morning. I think the difference between it working and not working is how long it has been sitting there waiting for user input. It is Monday morning and everyone in the office with me running Ubuntu has had this problem. The Update Manager has probably been sitting there since Saturday morning.

When the Install Updates button does not work clicking the Check button fixes it. If you click the Check button you will be prompted for your password. After the package list is updated the Install Updates button will install the updates.

My computer is working fine but I've installed 2 others that have this problem. The only difference that I know of, is the 2 others are using a French version.

I don't know if it can help.

This bug is still present in Lucid. From my experience, if you respond to the automatically opened update-manager shortly after it's opened the Install button functions fine. However, if update-manager has opened while I was away from the system and then I come back some time later the button is unresponsive. The behavior has been the same for Karmic and now Lucid.

I agree with James W. Collins, the bug is still present and has been since early Karmic beta days if not longer.

Also I agree with the observation that it seems to work if you click the Install button shortly after the popup has appeared.

Usually when I encounter this bug my machine has been left idle for hours, sometimes overnight, so the popup could have been on the screen for a long time.

After Install didn't work this morning, I just clicked Check and Install before opening the bug report page and finding this bug, so the install had already been run and I'm not sure if the stuff in my .xession-errors is from the error or the subsequent succesful install run but it did have a python traceback from the update notifier:

Traceback (most recent call last):
  File "/usr/lib/python2.6/dist-packages/UpdateManager/UpdateManager.py", line 586, in on_button_install_clicked
    self.cache.checkFreeSpace()
  File "/usr/lib/python2.6/dist-packages/DistUpgrade/DistUpgradeCache.py", line 1095, in checkFreeSpace
    for (dir, size) in [(archivedir, self.requiredDownload),
  File "/usr/lib/python2.6/dist-packages/UpdateManager/Core/MyCache.py", line 88, in requiredDownload
    pm.GetArchives(fetcher, self._list, self._records)
SystemError: E:I wasn't able to locate file for the language-pack-en package. This might mean you need to manually fix this package.
Traceback (most recent call last):
  File "/usr/lib/python2.6/dist-packages/UpdateManager/UpdateManager.py", line 586, in on_button_install_clicked
    self.cache.checkFreeSpace()
  File "/usr/lib/python2.6/dist-packages/DistUpgrade/DistUpgradeCache.py", line 1095, in checkFreeSpace
    for (dir, size) in [(archivedir, self.requiredDownload),
  File "/usr/lib/python2.6/dist-packages/UpdateManager/Core/MyCache.py", line 88, in requiredDownload
    pm.GetArchives(fetcher, self._list, self._records)
SystemError: E:I wasn't able to locate file for the language-pack-en package. This might mean you need to manually fix this package.
Traceback (most recent call last):
  File "/usr/lib/python2.6/dist-packages/UpdateManager/UpdateManager.py", line 586, in on_button_install_clicked
    self.cache.checkFreeSpace()
  File "/usr/lib/python2.6/dist-packages/DistUpgrade/DistUpgradeCache.py", line 1095, in checkFreeSpace
    for (dir, size) in [(archivedir, self.requiredDownload),
  File "/usr/lib/python2.6/dist-packages/UpdateManager/Core/MyCache.py", line 88, in requiredDownload
    pm.GetArchives(fetcher, self._list, self._records)
SystemError: E:I wasn't able to locate file for the language-pack-en package. This might mean you need to manually fix this package.
** (update-notifier:22626): DEBUG: --security-updates-unattended: 0

It just happened again, on my netbook this time, and even though I pressed "Install Updates" immediately as the notifier came up, it didn't work. This time it looks like it's another language pack that is causing the problem and this time I know for sure that the error in .xsession-errors is from this because I didn't click "Check" before I looked.

See the output at the end of the attached .xsession-errors file.

/var/log/dpkg/status added as requested above.

Why is this bug marked "Invalid" for update-manager?

I think this is a serious problem as it affects visibility for people browsing update-manager's bugs. This bug needs attention, it is detrimental to the experience of novice users who don't figure out that they have to press "Check", so please correct this!

On the same computer as originally reported. Upgraded said machine from 9.04 to 9.10 and then later to 10.04. The same bug still persists in all versions.

Bug persists on a freshly installed 10.04. Russian locale here.

Reproducible on a fresh lucid 32bit install here too:

- launch u-m from a terminal.
- wait a few hours (Hmm, I wonder if an apt-get update in another terminal would have also worked?)
- click Install Updates. Nothing happens, but there is a message on the terminal:

Traceback (most recent call last):
  File "/usr/lib/python2.6/dist-packages/UpdateManager/UpdateManager.py", line 586, in on_button_install_clicked
    self.cache.checkFreeSpace()
  File "/usr/lib/python2.6/dist-packages/DistUpgrade/DistUpgradeCache.py", line 1104, in checkFreeSpace
    for (dir, size) in [(archivedir, self.requiredDownload),
  File "/usr/lib/python2.6/dist-packages/UpdateManager/Core/MyCache.py", line 88, in requiredDownload
    pm.GetArchives(fetcher, self._list, self._records)
SystemError: E:I wasn't able to locate file for the linux-image-2.6.32-23-generic package. This might mean you need to manually fix this package.

I would have attached /var/log/dpkg/status, but /var/log/dpkg/ does not exist. :P

Seeing the same bug here on Lucid 64-bit, with the same SystemError in .xsession-errors:

Traceback (most recent call last):
  File "/usr/lib/python2.6/dist-packages/UpdateManager/UpdateManager.py", line 586, in on_button_install_clicked
    self.cache.checkFreeSpace()
  File "/usr/lib/python2.6/dist-packages/DistUpgrade/DistUpgradeCache.py", line 1104, in checkFreeSpace
    for (dir, size) in [(archivedir, self.requiredDownload),
  File "/usr/lib/python2.6/dist-packages/UpdateManager/Core/MyCache.py", line 88, in requiredDownload
    pm.GetArchives(fetcher, self._list, self._records)
SystemError: E:I wasn't able to locate file for the linux-image-2.6.32-24-generic package. This might mean you need to manually fix this package.

FYI, Jean-Baptiste meant to say /var/lib/dpkg/status, not /var/log/dpkg/status.

I'm experiencing the same bug, running 10.04.1 LTS.

/var/lib/dpkg/status attached.

Clicking "check" button workaround works for me.

Just added it to the Paper cut project since I believe this to be the kind of usability bug that paper cut project intends to fix.
I'm not really sure about the workload to solve it though.
I hope someone will have enough knowledge of update manager to triage it.

I'm seeing this problem on my 3 systems that run ubuntu 10.04 (2 x 64bit and 1 x 32bit). I have had to use the "check" button workaround since I first installed 10.04. I finally got annoyed that such seemingly simple functionality is still broken, found this bug report while looking for a solution, and decided to add my 2 cents.

This was reported over a year ago and concerns a core feature. It's an annoying, stupid little bug that degrades the overall Ubuntu experience for beginners as well as seasoned users.

Why is this still left as "undecided" importance? I think it needs to be accelerated by now. And fixed - yesterday...

In my case changing permissions helped:

sudo chmod 755 /var/cache/apt /var/cache/apt/archives /var/cache/apt/archives/partial

(Originally they were all 700 with owner as root.)

I have a fresh install of 10.4 on a Lenovo T61. I see this bug when the system is comming out of sleep and the system has detected there are update to apply. i have learned to press the "Check" button before pressing the "Install Updates" to get the sudo prompt. It is more of a nusense, but the bug still is there.

I have seen this issue on one of my machines too.
The particular machine that has the problem is also set to FRENCH, while others left to default English do not show this problem. Maybe having a different locale is the cause of this problem.

I am having an issue similar to this on 2 out of 3 systems running 10.10. The one system that is not having this issue is a fresh install, still running the stock window manager. Others are dist-upgrades running fluxbox. I apologize if I am posting this in the wrong place, I see that several people have reported different symptoms. Since my problem description is slightly different than some others, I'll run through what I see, comparatively.

- Install Updates is available, but does not install updates when clicked (like everyone else).
- No combination of clicking Check or Settings will make the Install Updates button function as expected.
- Prior to updating to 10.10, clicking Check or Settings, then Install Updates would usually work as expected.
- Checking or un-checking any number of packages to be updated has not shown any different response.
- The updates will install without error via command line; sudo apt-get update; sudo apt-get upgrade
- Updates will also install without error via synaptic; click Mark All Upgrades, then click Apply.
- I get no errors from update-manager (either when running from terminal, or in .xsession-errors).
- Running sudo aptd -td in one terminal and clicking on Install Updates yields an info message like the following;

with only one package selected:
20:58:57 AptDaemon [INFO]: CommitPackages() was called: dbus.Array([dbus.String(u'')], signature=dbus.Signature('s')), dbus.Array([dbus.String(u'')], signature=dbus.Signature('s')), dbus.Array([dbus.String(u'')], signature=dbus.Signature('s')), dbus.Array([dbus.String(u'')], signature=dbus.Signature('s')), dbus.Array([dbus.String(u'ubuntu-docs')], signature=dbus.Signature('s'))

with several packages selected:
21:00:48 AptDaemon [INFO]: CommitPackages() was called: dbus.Array([dbus.String(u'')], signature=dbus.Signature('s')), dbus.Array([dbus.String(u'')], signature=dbus.Signature('s')), dbus.Array([dbus.String(u'')], signature=dbus.Signature('s')), dbus.Array([dbus.String(u'')], signature=dbus.Signature('s')), dbus.Array([dbus.String(u'icedtea-6-jre-cacao'), dbus.String(u'icedtea6-plugin'), dbus.String(u'libc-bin'), dbus.String(u'libc-dev-bin'), dbus.String(u'libc6'), dbus.String(u'libc6-dbg'), dbus.String(u'libc6-dev'), dbus.String(u'libc6-i386'), dbus.String(u'openjdk-6-jre'), dbus.String(u'openjdk-6-jre-headless'), dbus.String(u'openjdk-6-jre-lib'), dbus.String(u'ubuntu-docs')], signature=dbus.Signature('s'))

strace output from aptd between idle states is attached. And from update-manager (attached before pressing Install Updates, and killed shortly after returning to idle loop) will be attached to the next post.

Note: I have been quietly tolerating this issue for over a year as the workaround of clicking Check before Install Updates was trivial. Even at this point, having no such simple workaround, I spent several months doing updates from command line since I had previously been trained to work around issues with the update manager. I suspect that there are many more people affected by this bug who are similarly tolerating it following the mild introduction and gentle symptom ramp up.

If there are any suggestions for things to try, I would be...

strace output from update-manager (attached before pressing Install Updates, and killed shortly after returning to idle loop) is attached.

I am marking this as invalid for the paper cuts project since a paper cut should be a small usability flaw that has been included in Ubuntu by design, whereas this is simply a bug.

Colan, you tagged this bug as "precise". Are you experiencing it in 12.04?

I continue to see this problem under 12.04, however the workaround has become a learned behavior. It's only because I sometimes fail to remember to press the check button that I continue to see the bug. It's been three years since 9.04. Another year or so and I'll be so well trained that I won't even notice that the bug ever gets fixed. (Sorry if that comes off as snide, but I'm trying to find the humor in the situation.)

-------- Original Message --------
 From: Matthew Paul Thomas <email address hidden>
 Sent: Thu, 15/11/2012 11:45 AM
 To: <email address hidden>
 CC:
 Subject: [Bug 414181] Re: "Install Updates" button does nothing when Update Manager opened by itself

>Colan, you tagged this bug as "precise". Are you experiencing it in
>12.04?
>
>** Description changed:
>
>- Ubuntu 9.04;
>+ Ubuntu 9.04, Ubuntu 10.04, Ubuntu 10.10
>+
> Update manager loads periodically and informs of new updates available. Clicking "Install Updates" button does nothing.
> The expected behavior (for this user) is that it ask for administrative password and then install the updates.
> However, if the "Check" button is clicked, then Admin Pass is requested, check is performed, and "Install Updates' button becomes active.
>
> Once learned this is only an annoyance. If this is the correct
> behavior, the install updates button should be greyed or a notice given
> to recheck before installing.
>
> WORKAROUND:
> click "check updates" before clicking on "install"
>
>--
>You received this bug notification because you are subscribed to a
>duplicate bug report (488324).
>https://bugs.launchpad.net/bugs/414181
>
>Title:
> "Install Updates" button does nothing when Update Manager opened by
> itself
>
>Status in One Hundred Paper Cuts:
> Invalid
>Status in Software Updater:
> Invalid
>Status in “update-manager” package in Ubuntu:
> Triaged
>
>Bug description:
> Ubuntu 9.04, Ubuntu 10.04, Ubuntu 10.10
>
> Update manager loads periodically and informs of new updates available. Clicking "Install Updates" button does nothing.
> The expected behavior (for this user) is that it ask for administrative password and then install the updates.
> However, if the "Check" button is clicked, then Admin Pass is requested, check is performed, and "Install Updates' button becomes active.
>
> Once learned this is only an annoyance. If this is the correct
> behavior, the install updates button should be greyed or a notice
> given to recheck before installing.
>
> WORKAROUND:
> click "check updates" before clicking on "install"
>
>To manage notifications about this bug go to:
>https://bugs.launchpad.net/hundredpapercuts/+bug/414181/+subscriptions

@Matthew: I was getting it in 12.04, yes. But now that I've upgraded to 12.10, where "Check updates" is done automatically on starting update-manager, it is no longer a problem.

Since it's affecting the LTS then this is still both a bug and a paper cut. We should do two things here:

1. Figure out what it is that's causing the 'Install Updates' button to do nothing without first checking for updates.
2. Backport both the first for the above point, as well as the automatic update check (because that's actually quite handy), to 12.04.

The reason that point #1 is important is that there could be some updates that were found during the last check but not installed for whatever reason, so the update manager could be sitting there with a list of available update and no way to install them.

Downgrading from Triaged to Confirmed since no one has stated on this bug report what is causing the faulty behaviour.

The faulty behaviour will be because the packages list is outdated, and could be reproduced like this:

1. From the application "software sources", change the update server.
2. Try to update the system using the "update manager" application.

Could you update the system doing this? If not, try this:

1. In the application "terminal", write "sudo apt-get update"
2. Try to update the system using the "update manager" application.

Does it work now? I'm all right this is the origin of the bug? because it happened many time ago for me.

I also wanted to know why the bug is assigned to nobody at this time in the papercut project 😵?

Alberto, to me, I thought this was a simple issue that could possibly have been fixed in the user interface. I thought that this was code that was created particularly for ubuntu, and therefore the excuses espoused in the top critical bug in the hundredpapercuts project didn't apply. I thought that having a significant usability issue in the update-manager would qualify as a "paper cut", but according to post #28, since it's simply a "bug" it apparently didn't qualify. I thought that this was a simple bug that could/should have been fixed in 2009, but now that it's 2013, I'm wondering if there's anyone at the wheel, let alone asleep at it.

In my little brain, it seems like the "check" button does roughly a "sudo apt-get update" and the "install" button should do a "sudo apt-get dist-upgrade". But something is wrong with the install button code. Since sudo has the property that the password only gets asked for every 15 minutes or so, it could be that pressing the "check" button makes install work simply because it's doing the "sudo". It also could be that the "apt-get update" part somehow greases the skids and makes the "install" button work, but I personally think it's more likely a privilege escalation issue. It doesn't make sense to me that without the "apt-get update" that the "install" should do nothing even when there are updates displayed in the window. That the "check" button may or may not bring up additional updates seems irrelevant.

If you take Alberto's example, and instead of trying "sudo apt-get update" you try "sudo apt-get dist-install" I think you'll find that the dist-install proceeds as expected. You might also try "sudo uptime" to see if it also fixes the install button. You might also try pressing the "check" button and waiting an hour to see if the "install" button now fails.

...and if we're talking about usability here, the fact that there's an "check" button at all is kind of stupid - the app should be checking periodically for additional updates just so the list of updates isn't out of date - after all, that's the purpose of the window anyway - to alert the user of updates to the system. ...but that would be an "enhancement" request that will be addressed at even lower priority...not to mention that it might break the workaround for this bug that we've been using for four years. ;-)

Sorry, I didn't read the bug report carefully enough.

On Wednesday, 29 May 2013, Craig Hansen wrote:

> Alberto, to me, I thought this was a simple issue that could possibly
> have been fixed in the user interface. I thought that this was code that
> was created particularly for ubuntu, and therefore the excuses espoused
> in the top critical bug in the hundredpapercuts project didn't apply. I
> thought that having a significant usability issue in the update-manager
> would qualify as a "paper cut", but according to post #28, since it's
> simply a "bug" it apparently didn't qualify. I thought that this was a
> simple bug that could/should have been fixed in 2009, but now that it's
> 2013, I'm wondering if there's anyone at the wheel, let alone asleep at
> it.
>
> In my little brain, it seems like the "check" button does roughly a
> "sudo apt-get update" and the "install" button should do a "sudo apt-get
> dist-upgrade". But something is wrong with the install button code.
> Since sudo has the property that the password only gets asked for every
> 15 minutes or so, it could be that pressing the "check" button makes
> install work simply because it's doing the "sudo". It also could be that
> the "apt-get update" part somehow greases the skids and makes the
> "install" button work, but I personally think it's more likely a
> privilege escalation issue. It doesn't make sense to me that without the
> "apt-get update" that the "install" should do nothing even when there
> are updates displayed in the window. That the "check" button may or may
> not bring up additional updates seems irrelevant.
>
> If you take Alberto's example, and instead of trying "sudo apt-get
> update" you try "sudo apt-get dist-install" I think you'll find that the
> dist-install proceeds as expected. You might also try "sudo uptime" to
> see if it also fixes the install button. You might also try pressing the
> "check" button and waiting an hour to see if the "install" button now
> fails.
>
> ...and if we're talking about usability here, the fact that there's an
> "check" button at all is kind of stupid - the app should be checking
> periodically for additional updates just so the list of updates isn't
> out of date - after all, that's the purpose of the window anyway - to
> alert the user of updates to the system. ...but that would be an
> "enhancement" request that will be addressed at even lower
> priority...not to mention that it might break the workaround for this
> bug that we've been using for four years. ;-)
>
> --
> You received this bug notification because you are subscribed to One
> Hundred Paper Cuts.
> Matching subscriptions: Papercut bug mail
> https://bugs.launchpad.net/bugs/414181
>
> Title:
> "Install Updates" button does nothing when Update Manager opened by
> itself
>
> Status in One Hundred Paper Cuts:
> Confirmed
> Status in Software Updater:
> Invalid
> Status in “update-manager” package in Ubuntu:
> Confirmed
>
> Bug description:
> Occurs in: Ubuntu 9.04, Ubuntu 10.04, Ubuntu 10.10, Ubuntu 12.04
> Does not occur in: Ubuntu 12.10
>
> Update manager loads periodically and informs of new updates available.
> Clicking "Install Updates" b...

This issue is still confirmed in 12.04.4 LTS after following the steps here https://help.ubuntu.com/community/QuantalUpgrades. The update manager does not look for 12.10 upgrade. Additionally, I checked /etc/update-manager/release-upgrades and set Prompt=normal and the "P" in prompt is lowercase. Please advise

This version is no more supported

That is incorrect: Ubuntu 12.04 is supported until April 2017.

Really looks a deprecated report: latest dupe was a 'Lucid' one, and #38 above point to a 'Quantal' to 'Precise' dist-upgrade.
That is, no more complaint reported; and no dev activity since 2009 related to that report.

[Expired for update-manager (Ubuntu) because there has been no activity for 60 days.]

Ubuntu 12.04 comfirmed still has this bug. Ubuntu 12.04 still supposed to be supported until April 2017.
Regrettably, this bug was submitted in 2009, and if the policy is to ignore bugs that aren't addressed in 60 days, this system is really just a mockery of the idea of support. This bug has been studiously reported, comfirmed, upgraded, downgraded, pushed, filed, stamped, indexed, briefed, debriefed, numbered, marked incomplete, and now expired.

I hereby propose changing it back to "confirmed."

@craig-hansen: If this is still an issue for 12.04 that you have recently observed, I recommend setting it back to confirmed.

Craig, I appreciate that this is aggravating, but a bug tracker is not a support system. It is a system for helping a finite number of developers make best use of their time. A bug that -- while annoying -- is relatively minor, has a workaround, and probably was fixed three years ago, probably will not attract the attention of many developers.

There are several ways you could attract a developer's attention to it. One would be to pay them to work on it. Another would be to raise the issue anywhere *except* this bug report, since everyone subscribed to this bug report already knows that the issue exists.

Another would be to do some of the work yourself, to make the rest of the work easier. Assuming that the bug is already fixed in 12.10 and later, the goal here would be a stable release update (SRU) for 12.04 that includes the fix. <https://wiki.ubuntu.com/StableReleaseUpdates> The first step would be to identify the particular change between 12.04 and 12.10 that fixed the bug, so that a new version containing only that fix can be issued.