[karmic] update-manager asks for password twice when there are both upgrades and new installs

Thanks for the bug report. I can confirm the bug on Karmic.

Thanks Nicolas. Did you notice if there were both new packages and updates to existing ones when you were asked to enter the password twice? Just curious.

Last time when I got this bug there were both new installs and upgrades. I don't know whether it happens when there are only upgrades.

I've had this quite a few times. When it happens I normally get the Applying Changes window stuck on "Waiting for other tasks".

I think it often happens when I run update-manager for the second time without a reboot, and after the reboot it works fine.

Let me know if there are any specific tests to run, output wanted when this does happen etc. And I'm on karmic x86_64.

Also tried to install a package at the command line after this happened (sudo aptitude install) and got

E: Could not get lock /var/lib/dpkg/lock - open (11: Resource temporarily unavailable)
E: Unable to lock the administration directory (/var/lib/dpkg/), is another process using it?
...

And I then tried:

$ sudo lsof | grep /var/lib/dpkg
lsof: WARNING: can't stat() fuse.gvfs-fuse-daemon file system /home/mish/.gvfs
      Output information may be incomplete.
aptd 10951 root 35r REG 252,1 2666426 1203792 /var/lib/dpkg/status (deleted)
aptd 11291 root 35r REG 252,1 2666426 1203792 /var/lib/dpkg/status (deleted)
dpkg 13422 root 3uW REG 252,1 0 1196053 /var/lib/dpkg/lock
dpkg 13422 root 4w REG 252,1 4608 1197139 /var/lib/dpkg/updates/tmp.i
dpkg 13422 root 5u REG 252,1 0 1196056 /var/lib/dpkg/triggers/Lock
dpkg 13422 root 7r REG 252,1 2225 1199016 /var/lib/dpkg/diversions
dpkg 13422 root 8r REG 252,1 193 1197440 /var/lib/dpkg/statoverride

$ ps -ef | grep 13422
root 13422 11291 11 21:10 pts/1 00:00:16 /usr/bin/dpkg --status-fd 10 --unpack --auto-deconfigure /var/cache/apt/archives/console-setup_1.34ubuntu4_all.deb /var/cache/apt/archives/libglib2.0-dev_2.22.1-0ubuntu1_amd64.deb /var/cache/apt/archives/libglib2.0-0-dbg_2.22.1-0ubuntu1_amd64.deb /var/cache/apt/archives/libglib2.0-0_2.22.1-0ubuntu1_amd64.deb /var/cache/apt/archives/ubuntu-minimal_1.172_amd64.deb /var/cache/apt/archives/apparmor_2.3.1+1403-0ubuntu24_amd64.deb /var/cache/apt/archives/libapparmor1_2.3.1+1403-0ubuntu24_amd64.deb /var/cache/apt/archives/libapparmor-perl_2.3.1+1403-0ubuntu24_amd64.deb /var/cache/apt/archives/apparmor-utils_2.3.1+1403-0ubuntu24_amd64.deb /var/cache/apt/archives/ubuntu-standard_1.172_amd64.deb /var/cache/apt/archives/app-install-data_0.9.10.9_all.deb /var/cache/apt/archives/byobu_2.36-0ubuntu1_all.deb /var/cache/apt/archives/libgnome-menu2_2.28.0.1-0ubuntu1_amd64.deb /var/cache/apt/archives/gnome-control-center_1%3a2.28.0-0ubuntu3_amd64.deb /var/cache/apt/archives/capplets-data_1%3a2.28.0-0ubuntu3_all.deb /var/cache/apt/archives/libgnome-window-settings1_1%3a2.28.0-0ubuntu3_amd64.deb /var/cache/apt/archives/libxklavier15_4.0-0ubuntu3_amd64.deb /var/cache/apt/archives/gnome-settings-daemon_2.28.0-0ubuntu2_amd64.deb /var/cache/apt/archives/gnome-menus_2.28.0.1-0ubuntu1_amd64.deb /var/cache/apt/archives/python-gmenu_2.28.0.1-0ubuntu1_amd64.deb /var/cache/apt/archives/couchdb_0.10.0~svn818859-0ubuntu1_all.deb /var/cache/apt/archives/couchdb-bin_0.10.0~svn818859-0ubuntu1_amd64.deb /var/cache/apt/archives/libcups2-dev_1.4.1-4_amd64.deb /var/cache/apt/archives/libcups2_1.4.1-4_amd64.deb /var/cache/apt/archives/libcupscgi1_1.4.1-4_amd64.deb /var/cache/apt/archives/libcupsdriver1_1.4.1-4_amd64.deb /var/cache/apt/archives/libcupsimage2_1.4.1-4_amd64.deb /var/cache/apt/archives/libcupsmime1_1.4.1-4_amd64.deb /var/cache/apt/archives/libcupsppdc1_1.4.1-4_amd64.deb /var/cache/apt/archives/cups-co...

Having just done all that, it appears that the install completed in the background - the restart required window appeared, and checking at the command line I can install again.

So it appears that one of the password windows does start the install but doesn't show the window to the user. And the second password entry tries to start the install but finds dpkg already running and so then blocks.

It might be relevant that I think this generally press the Check button first, but I do this a lot, and only sometimes do I get the two password boxes and the blocking behaviour.

Actually this is a policy decision. Currently there are separate priviliges for installing and updating packages. The CommitPackages mehtods checks if each one of them is required.

I cannot think of a use case in which somebody is allowed to install software but not allowed to upgrade software.

But note that the reverse (can upgrade but not install) could be useful :)
So the installation privilege should include upgrade privileges, but not the other way around.

harmish: The hanging progress dialog is a separate issue. See #441304

This bug was fixed in the package aptdaemon - 0.10+bzr258-0ubuntu1

---------------
aptdaemon (0.10+bzr258-0ubuntu1) karmic; urgency=low

  * New upstream snapshot:
    - fix hang in authentication dialog (LP: #426720)
    - don't ask for authentication twice (LP: #437094)
    - better handling for broken dependencies
  * remove mvo-branch.patch, disallow-unauthenticated-branch.diff
    both got merged upstream
  * debian/patches/fix_syslog_crash.patch:
    - fix crash if no syslogd is installed
  * aptdaemon/worker.py:
    - test lock of the apt download dir as well

 -- Michael Vogt <email address hidden> Tue, 06 Oct 2009 09:01:10 +0200

This is still happening, just now as I updated. Asks for password to check then again to install.

philinux: thanks for your input, but I think your issue is a separate issue - please file a separate bug for it.

This bug was about when you click install, and then you get asked for your password twice just for clicking install. That no longer happens.

However, I think this bug may have been only partially fixed. I never get asked for the password twice when clicking install, but update-manager now only seems to do updates, it never seems to install new packages required by meta-packages that have been updated to have a new Depends: item. For example, update-manager leaves linux-image-generic greyed out when I do an update. I try doing

$ sudo aptitude install linux-image-generic

in a terminal and it works fine - so the new dependency is available, but update-manager refuses to install it. Do other people notice this behaviour? Should this be a new bug? Is it already a new bug?

Ok created new bug report. 448952