Created attachment 273929 [details] emerge --info I'm not sure what caused this behaviour, because cryptsetup had worked flawlessly for years. I had done a emerge world and revdep-rebuild before (May 18, 2011 08:20:44GMT+02:00), which updated the following packages on my ~x86 system: sys-devel/bison-2.5 sys-apps/kbd-1.15.3 net-zope/zope-interface-3.6.2 app-admin/python-updater-0.9 app-portage/gentoolkit-0.3.0.3 x11-base/xorg-server-1.10.1 (downgrade) x11-drivers/ati-drivers-11.5 app-admin/sudo-1.8.1_p2 kde-misc/kcm-gtk-config-1.5 media-video/vlc-1.1.9-r1 After that, the following call to cryptsetup never terminated, just hanging: # sudo /sbin/losetup /dev/loop0 /path/to/LUKS-file (OK) # echo $passphrase | sudo /sbin/cryptsetup luksOpen /dev/loop0 crypted (hangs) A look at strace showed the process (cryptsetup) to hang on a semop operation: # strace -p 4008 semop(169925, {0, 0, 0}, 1) = A look at ipcs showed that semid 169925 was actually assigned to root and had 1 semaphore in the array: ------ Semaphore Arrays -------- key semid owner perms nsems 0x0056a4d5 169925 root 600 1 After removing the semaphore with # ipcrm -s 169925 (and the next two semaphores cryptsetup hung afterwards), the command finally terminated successfully. I assumed some library to be at fault, but /sbin/cryptsetup is not a dynamically linked binary: # file /sbin/cryptsetup /sbin/cryptsetup: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, for GNU/Linux 2.6.9, stripped I then remerged cryptsetup, and this solved the problem! This might not be a cryptsetup bug, but it seems that it should have been automatically rebuilt after another package had been updated.
Was there also a udev update? What is your current udev version?
From /var/log/emerge.log the only packages updated before cryptsetup stopped working were those already reported. The last udev update was from udev-168-r1 to udev-168-r2 on: May 16, 2011 11:31:52 From /var/log/messages (and own memory :-) the system was booted various times between that time and the last update (emerge), that resulted in cryptsetup hanging. The latest entry pointing to a reboot with subsequent successful cryptsetup is: ... May 18 17:27:22 envy syslog-ng[3417]: syslog-ng shutting down; version='3.2.4' May 18 15:28:01 envy syslog-ng[3210]: syslog-ng starting up; version='3.2.4' May 18 15:28:01 envy kernel: [ 0.000000] Initializing cgroup subsys cpuset May 18 15:28:01 envy kernel: [ 0.000000] Initializing cgroup subsys cpu May 18 15:28:01 envy kernel: [ 0.000000] Linux version 2.6.38-gentoo (root@envy) (gcc version 4.4.4 (Gentoo 4.4. 4-r2 p1.3, pie-0.4.5) ) #2 SMP PREEMPT Sun May 1 12:21:47 CEST 2011 ... May 18 15:29:27 envy cryptsetup: Setting up device mapping from /dev/loop0 to /dev/mapper/crypted May 18 15:29:27 envy sudo: user : TTY=unknown ; PWD=/home/user/Documents ; USER=root ; COMMAND=/sbin/cryptsetup luksOpen /dev/loop0 crypted (TTY=unknown is OK, since the commands are issued by a script started by KDE autostart) At which point cryptsetup was still working.
Please disregard my last post. I just realized that in fact the last successful cryptsetup run was on May 16 08:23:15 envy cryptsetup: Volume(s) mounted successfully So *before* the udev update (May 16, 2011 11:31:52).
(In reply to comment #3) > Please disregard my last post. I just realized that in fact the last successful > cryptsetup run was on > May 16 08:23:15 envy cryptsetup: Volume(s) mounted successfully > > So *before* the udev update (May 16, 2011 11:31:52). Does it work again when emerging the udev version that was there before?
try with latest udev/cryptsetup and see if it's still a prob
(In reply to comment #5) > try with latest udev/cryptsetup and see if it's still a prob It has actually worked ever since. This report actually was not about cryptsetup not working, but rather about revdep-rebuild not picking up the udev update and rebuilding it. But this is probably not possible, as it is not a matter of missing libraries for linking ...
