Comment 41 for bug 635698

I ran Lubuntu 10.10 in a virtualbox VM, added a user with an encrypted home directory and demonstrated the original bug. Enabled -proposed, updated the world, rebooted the VM, and verified I can now access that encrypted home directory immediately after login.

Since I am running virtualbox-ose I cannot test the USB stick mount issues relating to libpam-ck-connector directly. I confirm the proposed lxdm package as a Conflicts: libpam-ck-connector entry, but that's as far as I can go with testing that.

However, there is *another* rather nasty encryption-related issue that appears, and I am not sure whether it is related to this fix or not: after doing all the above (installed Lubuntu, update it, add a user with an encrypted home, add -proposed to sources, update and upgrade, reboot, verify encrypted home user now automounts his home), it seems that apt-get autoremove tries to remove packages it should be leaving well alone:

sudo apt-get autoremove -s
[sudo] password for jonathan:
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages will be REMOVED:
  cryptsetup dmraid ecryptfs-utils keyutils libdebconfclient0
  libdmraid1.0.0.rc16 libecryptfs0 linux-headers-2.6.35-22
  linux-headers-2.6.35-22-generic localechooser-data ndiswrapper-common
  python-pyicu python-webkit rdate reiserfsprogs
0 upgraded, 0 newly installed, 15 to remove and 0 not upgraded.

If a real (not simulated) apt-get remove is attempted after the user with the encrypted home has logged in, bad things happen:

The following packages will be REMOVED:
  cryptsetup dmraid ecryptfs-utils keyutils libdebconfclient0
  libdmraid1.0.0.rc16 libecryptfs0 linux-headers-2.6.35-22
  linux-headers-2.6.35-22-generic localechooser-data ndiswrapper-common
  python-pyicu python-webkit rdate reiserfsprogs
0 upgraded, 0 newly installed, 15 to remove and 21 not upgraded.
After this operation, 94.4MB disk space will be freed.
Do you want to continue [Y/n]? y
(Reading database ... 97781 files and directories currently installed.)
Removing cryptsetup ...
update-initramfs: deferring update (trigger activated)
Removing dmraid ...
update-initramfs: deferring update (trigger activated)
Removing ecryptfs-utils ...
ERROR: Cannot remove ecryptfs-utils, as it appears to be in use:
       [/home/eh/.ecryptfs]
dpkg: error processing ecryptfs-utils (--remove):
 subprocess installed pre-removal script returned error exit status 1
Removing libdebconfclient0 ...
Removing libdmraid1.0.0.rc16 ...
Removing linux-headers-2.6.35-22-generic ...
Removing linux-headers-2.6.35-22 ...
Removing localechooser-data ...
Removing ndiswrapper-common ...
Removing python-pyicu ...
Removing python-webkit ...
Removing rdate ...
Removing reiserfsprogs ...
dpkg: keyutils: dependency problems, but removing anyway as you requested:
 ecryptfs-utils depends on keyutils; however:
  Package keyutils is to be removed.
Removing keyutils ...
dpkg: libecryptfs0: dependency problems, but removing anyway as you requested:
 ecryptfs-utils depends on libecryptfs0 (>= 77); however:
  Package libecryptfs0 is to be removed.
Removing libecryptfs0 ...
Processing triggers for man-db ...
Processing triggers for ureadahead ...
Processing triggers for initramfs-tools ...
update-initramfs: Generating /boot/initrd.img-2.6.35-25-generic
Processing triggers for libc-bin ...
ldconfig deferred processing now taking place
Processing triggers for python-support ...
Errors were encountered while processing:
 ecryptfs-utils
E: Sub-process /usr/bin/dpkg returned an error code (1)

Now autoremove just broke our dependencies, we have ecryptfs-utils installed but not some of its dependencies keyutils and libecryptfs0 ! This is not supposed to happen!

At this point, logging back in as the user with the encrypted home directory (user eh in my test, EH stands for Encrypted Home!) no longer mounts his directory, and worse yet, trying to mount it manually generates an error

  ecryptfs-mount-private
 Enter your login passphrase:
 ecryptfs-insert-wrapped-passphrase-into-keyring: error while loading shared libraries: libecryptfs.so.0: cannot open shared object file: No such file or directory
 ERROR: Your passphrase is incorrect
 Enter your login passphrase:

I rather doubt the proposed change to lxdm is responsible for this mess, but... the end result after installing the updated lxdm and then doing apt-get autoremove is *very* bad. My strong suspicion is that something does not depend on ecryptfs-utils that really *needs* to depend on them.

Sorry I couldn't provide a clean green light verification, I hope this information is useful in looking further at this.