Summary: | sys-fs/udev-197 breaks cryptsetup luksOpen | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Thomas Witt <bugs> |
Component: | [OLD] Core system | Assignee: | udev maintainers <udev-bugs> |
Status: | RESOLVED INVALID | ||
Severity: | normal | CC: | alexander, bugs-gentoo, gentoo-bugs, jdavid.ibp, krinpaus, kripton, mark.morschhaeuser, Martin.vGagern, tomwij |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Thomas Witt
2013-01-10 17:27:45 UTC
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 |