I use an encrypted partition for /home that is mounted on login by pam_mount. After upgrading udev to 197, cryptsetup luksOpen hangs after entering the passphrase. Reproducible: Always Steps to Reproduce: 1. upgrade udev to 197 2. reboot Actual Results: gdm hangs on login / cryptsetup luksOpen hangs after entering passphrase Expected Results: After downgrading to udev-196-r1, the partition gets monted on login. $cave info udev Package Manager Information: Package Name paludis Package Version 0.82.0 Build Date 2012-11-19T08:54:48+0100 Built with CXX x86_64-pc-linux-gnu-g++ 4.6.3 Built with CXXFLAGS -march=native -O3 -pedantic Built with LDFLAGS -Wl,-O1 -Wl,--as-needed Environment Information: Format paludis Config dir /etc/paludis Root / System Root / World file /var/db/pkg/world Repository layman: format unavailable location /var/paludis/repositories/layman sync tar+http://git.exherbo.org/layman_repositories.tar.bz2 sync_options Repository gentoo: format e location /var/paludis/repositories/gentoo builddir /var/tmp/paludis cache /var/paludis/repositories/gentoo/metadata/md5-cache distdir /var/paludis/distfiles eapi_when_unknown 0 eapi_when_unspecified 0 eclassdirs /var/paludis/repositories/gentoo/eclass layout traditional manifest_hashes SHA256 SHA512 WHIRLPOOL names_cache /var/cache/paludis/names newsdir /var/paludis/repositories/gentoo/metadata/news profile_eapi_when_unspecified 0 profile_layout traditional profiles /var/paludis/repositories/gentoo/profiles/default/linux/amd64/10.0/desktop securitydir /var/paludis/repositories/gentoo/metadata/glsa setsdir /var/paludis/repositories/gentoo/sets sync rsync://rsync.de.gentoo.org/gentoo-portage sync_options thin_manifests false use_manifest use write_cache /var/empty Package information app-shells/bash 4.2_p42 dev-java/java-config 2.1.12-r1 dev-lang/python 2.7.3-r3 dev-util/ccache (none) dev-util/cmake 2.8.10.2-r1 dev-util/pkgconfig 0.27.1 sys-apps/baselayout 2.2 sys-apps/openrc 0.11.8 sys-apps/sandbox 2.6 sys-devel/autoconf 2.13 2.69 sys-devel/automake 1.11.6 1.12.6 sys-devel/binutils 2.23.1 sys-devel/gcc 4.6.3 sys-devel/gcc-config 1.8 sys-devel/libtool 2.4.2 sys-devel/make 3.82-r4 sys-freebsd/freebsd-lib (none) sys-kernel/linux-headers 3.7 sys-libs/glibc 2.16.0 sys-libs/uclibc (none) Repository sunrise: format e location /var/paludis/repositories/sunrise builddir /var/tmp/paludis cache /var/empty distdir /var/paludis/distfiles eapi_when_unknown 0 eapi_when_unspecified 0 eclassdirs /var/paludis/repositories/gentoo/eclass /var/paludis/repositories/sunrise/eclass layout traditional manifest_hashes SHA256 SHA512 WHIRLPOOL master_repository gentoo names_cache /var/cache/paludis/names newsdir /var/paludis/repositories/sunrise/metadata/news profile_eapi_when_unspecified 0 profile_layout traditional profiles /var/paludis/repositories/gentoo/profiles/default/linux/amd64/10.0/desktop securitydir /var/paludis/repositories/sunrise/metadata/glsa setsdir /var/paludis/repositories/sunrise/sets sync git://git.overlays.gentoo.org/proj/sunrise-reviewed.git git+http://git.overlays.gentoo.org/gitroot/proj/sunrise-reviewed.git git+ssh://git@git.overlays.gentoo.org/proj/sunrise-reviewed.git sync_options thin_manifests false use_manifest use write_cache /var/cache/paludis/metadata Repository installed: format vdb location /var/db/pkg builddir /var/tmp/paludis eapi_when_unknown 0 names_cache /var/cache/paludis/names root / Repository repository: format repository config_filename /etc/paludis/repositories/%{repository_template_name}.conf config_template /etc/paludis/repository.template root / Repository local: format e location /var/paludis/repositories/local builddir /var/tmp/paludis cache /var/empty distdir /var/paludis/distfiles eapi_when_unknown 0 eapi_when_unspecified 0 eclassdirs /var/paludis/repositories/gentoo/eclass /var/paludis/repositories/local/eclass layout traditional manifest_hashes SHA256 SHA512 WHIRLPOOL master_repository gentoo names_cache /var/cache/paludis/names newsdir /var/paludis/repositories/local/metadata/news profile_eapi_when_unspecified 0 profile_layout traditional profiles /var/paludis/repositories/gentoo/profiles/default/linux/amd64/10.0/desktop securitydir /var/paludis/repositories/local/metadata/glsa setsdir /var/paludis/repositories/local/sets sync sync_options thin_manifests false use_manifest use write_cache /var/empty Repository perl-experimental: format e location /var/paludis/repositories/perl-experimental builddir /var/tmp/paludis cache /var/empty distdir /var/paludis/distfiles eapi_when_unknown 0 eapi_when_unspecified 0 eclassdirs /var/paludis/repositories/gentoo/eclass /var/paludis/repositories/perl-experimental/eclass layout traditional manifest_hashes SHA256 SHA512 WHIRLPOOL master_repository gentoo names_cache /var/cache/paludis/names newsdir /var/paludis/repositories/perl-experimental/metadata/news profile_eapi_when_unspecified 0 profile_layout traditional profiles /var/paludis/repositories/gentoo/profiles/default/linux/amd64/10.0/desktop securitydir /var/paludis/repositories/perl-experimental/metadata/glsa setsdir /var/paludis/repositories/perl-experimental/sets sync git://git.overlays.gentoo.org/proj/perl-overlay.git git+http://git.overlays.gentoo.org/gitroot/proj/perl-overlay.git git+ssh://git@git.overlays.gentoo.org/proj/perl-overlay.git sync_options thin_manifests false use_manifest use write_cache /var/cache/paludis/metadata Repository poly-c: format e location /var/paludis/repositories/poly-c builddir /var/tmp/paludis cache /var/paludis/repositories/poly-c/metadata/md5-cache distdir /var/paludis/distfiles eapi_when_unknown 0 eapi_when_unspecified 0 eclassdirs /var/paludis/repositories/gentoo/eclass /var/paludis/repositories/poly-c/eclass layout traditional manifest_hashes SHA256 SHA512 WHIRLPOOL master_repository gentoo names_cache /var/cache/paludis/names newsdir /var/paludis/repositories/poly-c/metadata/news profile_eapi_when_unspecified 0 profile_layout traditional profiles /var/paludis/repositories/gentoo/profiles/default/linux/amd64/10.0/desktop securitydir /var/paludis/repositories/poly-c/metadata/glsa setsdir /var/paludis/repositories/poly-c/sets sync rsync://gentoofan.no-ip.org/poly-c sync_options thin_manifests false use_manifest use write_cache /var/cache/paludis/metadata Extra Information for sys-fs/udev-196-r1::installed: >>> Running ebuild phase killold as pyro:users... >>> Starting builtin_killold >>> Done builtin_killold >>> Completed ebuild phase killold >>> Running ebuild phases initmisc infovars info as pyro:users... >>> Starting builtin_initmisc
I could reproduce this bug and the workaround. I use Paludis, too. Is this Bug relatet to this packagemanager somehow? Can anybody reproduce this Bug with Portage?
confirm
(using portage/emerge)
Confirm. I downgraded udev and then upgraded again, this fixed it.
Have you tried to reemerge all packages that have rules installed in /usr/lib/udev/rules.d? for portage users: emerge -1av $(equery -q belongs -n /usr/lib/udev | xargs)
Was also experiencing, this, I ran the command Alexander posted, and everything is working nicely.
So you guys probably didn't read elog messages. :) udev-197 doesn't look for rules and helpers in /usr/lib/udev. AFAIK cryptestup need device-mapper rules which is owned by sys-fs/lvm2, and this rules installed in /usr/lib/udev/rules.d on your systems. From the ebuild: if [[ -d ${ROOT}usr/lib/udev ]] then ewarn "Please re-emerge all packages on your system which install" ewarn "rules and helpers in /usr/lib/udev. They should now be in" ewarn "/lib/udev." ewarn fi
*** Bug 451364 has been marked as a duplicate of this bug. ***
(In reply to comment #5) > Have you tried to reemerge all packages that have rules installed in > /usr/lib/udev/rules.d? > > for portage users: > emerge -1av $(equery -q belongs -n /usr/lib/udev | xargs) Ah, ewarn. (Did I mention I hate ewarn?) I propose something like the following for paludis users: cave resolve -x1 -0 '*/*' $(find /usr/lib/udev -exec qfile -qC {} /; |sort|uniq|xargs)
(In reply to comment #9) > cave resolve -x1 -0 '*/*' $(find /usr/lib/udev -exec qfile -qC {} /; > |sort|uniq|xargs) "qfile -qC /usr/lib/udev | xargs" should also work
Thank you all for your input. Reading the ewarn-messages fixed that for me.
*** Bug 451538 has been marked as a duplicate of this bug. ***
Grrr ... ewarn should contain this lines to for all lazy user like me : for portage users: emerge -1av $(equery -q belongs -n /usr/lib/udev | xargs)
*** Bug 451556 has been marked as a duplicate of this bug. ***
*** Bug 451410 has been marked as a duplicate of this bug. ***
*** Bug 451844 has been marked as a duplicate of this bug. ***
So let me get this straight: the udev-196-r1 ebuild told people "This version of udev moves the files which were installed in /lib/udev to /usr/lib/udev. We include a backward compatibility patch for gentoo to allow the rules in /lib/udev/rules.d to be read; however, bugs should be filed against packages which are installing things in /lib/udev so they can be fixed." We even had bug #433916 to keep track of this change. And just one version later, the message now reads "Please re-emerge all packages on your system which install rules and helpers in /usr/lib/udev. They should now be in /lib/udev." And people are expected to notice that this is a different message, and that disregarding said message might render their system unbootable. Don't get me wrong, I like this stuff in /lib/udev, and I hope that you will never dtabilize 196, so that you have a clean /lib/udev route without any intermediate /usr/lib/udev for stable users. But the message should be a bit more prominent and verbose, in my opinion. And a backward-compatible patch (similar to the one mentioned in the 196 elog) would be really nice. As it stands now, users who encounter a system crash or similar dusing the upgrade are in deep trouble. Usually the way portage installs packages is pretty atomic, but not so in this case. Therefore, having a version which accepts the old directory but forces packages to install stuff into the new one would be really great.
@Reporter: Importance fields should be set by the maintainer. @Maintainers: Although it's marked invalid, see comment #13 and comment #17.
(In reply to comment #13) > Grrr ... ewarn should contain this lines to for all lazy user like me : > > for portage users: > emerge -1av $(equery -q belongs -n /usr/lib/udev | xargs) This is done. (In reply to comment #17) > So let me get this straight: the udev-196-r1 ebuild told people > > "This version of udev moves the files which were installed in > /lib/udev to /usr/lib/udev. We include a backward compatibility > patch for gentoo to allow the rules in /lib/udev/rules.d to be > read; however, bugs should be filed against packages which are > installing things in /lib/udev so they can be fixed." > > We even had bug #433916 to keep track of this change. > And just one version later, the message now reads > > "Please re-emerge all packages on your system which install > rules and helpers in /usr/lib/udev. They should now be in > /lib/udev." > And people are expected to notice that this is a different message, and that > disregarding said message might render their system unbootable. > > Don't get me wrong, I like this stuff in /lib/udev, and I hope that you will > never dtabilize 196, so that you have a clean /lib/udev route without any > intermediate /usr/lib/udev for stable users. But the message should be a bit > more prominent and verbose, in my opinion. > That's correct. This issue only affected a ~arch version of udev and now we are moving things to be back in sync with upstream. This happened because of a misunderstanding of how their build system is supposed to work. I have added an example of the command you should run to fix this issue on your system, so now the message is more verbose. > And a backward-compatible patch (similar to the one mentioned in the 196 > elog) would be really nice. As it stands now, users who encounter a system > crash or similar dusing the upgrade are in deep trouble. Usually the way > portage installs packages is pretty atomic, but not so in this case. > Therefore, having a version which accepts the old directory but forces > packages to install stuff into the new one would be really great. Except that the old directory support never made it to stable in the first place, so if I do that, I would bring something to stable that I'm not quite comfortable bringing to stable.
*** Bug 452542 has been marked as a duplicate of this bug. ***
(In reply to comment #17) > We even had bug #433916 to keep track of this change. > And just one version later, the message now reads It is still valid Tracker. Packages need to read udevdir= from udev.pc, as in, use udev.eclass. One place to set the path, whatever it is. Futhermore packages can't install their rules to /etc/udev which is like installing binaries to /usr/local/bin.
(In reply to comment #21) > It is still valid Tracker. and stuff is harder to find one it has been set to RESOLVED. For the cryptsetup-breakage, rebuilding lvm2 is sufficient but of course the other packages might break other stuff with less dangerous consequences