I just recently switched over to sys-fs/eudev. So far so good, however I'm using sys-kernel/dracut to build my initramfs and this again/still hard-depends on sys-fs/udev. Currently I'm using dracut-024-r3 with eudev-1_beta1-r2 and didn't experience problems so far. In the ebuild changelog I then found the following comment from Amadeusz Żołnowski: "Revert dependency from virtual/udev to sys-fs/udev. Dracut need to be customized first to depend both on eudev and udev." Is it possible to check dracut (or eudev respectively) for the missing parts and make it again depending on virtua/udev? What are these parts? Reproducible: Always Actual Results: Just for reference, I add here the error message: [blocks B ] sys-fs/udev ("sys-fs/udev" is blocking sys-fs/eudev-1_beta1-r2) [blocks B ] <=sys-fs/udev-180 ("<=sys-fs/udev-180" is blocking sys-fs/eudev-1_beta1-r2) [blocks B ] <sys-fs/udev-186 ("<sys-fs/udev-186" is blocking sys-fs/udev-init-scripts-18) ... (sys-fs/udev-171-r9::gentoo, ebuild scheduled for merge) pulled in by >sys-fs/udev-166 required by (sys-kernel/dracut-024-r3::gentoo, installed) (sys-fs/eudev-1_beta1-r2::gentoo, installed) pulled in by >=sys-fs/eudev-1_beta1[gudev,hwdb,introspection,keymap,static-libs] required by (virtual/udev-196::gentoo, installed)
The dracut ebuilds already use virtual/udev. You must be confusing something. $ grep virtual/udev *.ebuild dracut-014-r3.ebuild: >=virtual/udev-164 dracut-018-r3.ebuild: >=virtual/udev-166 dracut-019-r6.ebuild: >=virtual/udev-166 dracut-022-r6.ebuild:CDEPEND=">=virtual/udev-166" dracut-023-r4.ebuild:CDEPEND=">virtual/udev-166 dracut-024-r2.ebuild:CDEPEND=">virtual/udev-166 dracut-024-r3.ebuild:CDEPEND=">virtual/udev-166
(In reply to comment #1) > The dracut ebuilds already use virtual/udev. You must be confusing something. > > $ grep virtual/udev *.ebuild > dracut-014-r3.ebuild: >=virtual/udev-164 > dracut-018-r3.ebuild: >=virtual/udev-166 > dracut-019-r6.ebuild: >=virtual/udev-166 > dracut-022-r6.ebuild:CDEPEND=">=virtual/udev-166" > dracut-023-r4.ebuild:CDEPEND=">virtual/udev-166 > dracut-024-r2.ebuild:CDEPEND=">virtual/udev-166 > dracut-024-r3.ebuild:CDEPEND=">virtual/udev-166 My bad. 05 Jan 2013; Amadeusz Żołnowski <aidecoe@gentoo.org> dracut-014-r3.ebuild, dracut-018-r3.ebuild, dracut-019-r6.ebuild, dracut-022-r6.ebuild, dracut-023-r4.ebuild, dracut-024-r2.ebuild, dracut-024-r3.ebuild: Revert dependency from virtual/udev to sys-fs/udev. Dracut need to be customized first to depend both on eudev and udev.
There are some small issues on eudev side with --version format being different, so file a bug wrt this problem first and add dependency to this bug, please. Moreover dracut needs to perform check if udev is linked with libkmod and generate rules using either BUILTIN or PROGRAM calls. Although the easiest way would be to depend on ( sys-fs/udev || sys-fs/eudev[kmod] ) and I probably will take this approach instead of depending on virtual/udev. Btw, Samuli, please don't do dependencies auto-replacements in the future. File bug instead.
(In reply to comment #3) > Btw, Samuli, please don't do dependencies auto-replacements in the future. > File bug instead. One bad hit among hundreds isn't that bad, but yes, I hear you :)
Please see bug #450162.
(In reply to comment #3) > There are some small issues on eudev side with --version format being > different, so file a bug wrt this problem first and add dependency to this > bug, please. > > Moreover dracut needs to perform check if udev is linked with libkmod and > generate rules using either BUILTIN or PROGRAM calls. Although the easiest > way would be to depend on ( sys-fs/udev || sys-fs/eudev[kmod] ) and I > probably will take this approach instead of depending on virtual/udev. > > Btw, Samuli, please don't do dependencies auto-replacements in the future. > File bug instead. We have a patch to fix this: https://github.com/gentoo/eudev/issues/36 We had no feedback from people using dracut and given the time of the year, doing the testing ourselves was delayed. Anyway, we will have this tested and into sys-fs/eudev soon. It should resolve this problem.
(In reply to comment #3) > Moreover dracut needs to perform check if udev is linked with libkmod and > generate rules using either BUILTIN or PROGRAM calls. Are you sure? I can't find any rules/rule generators in dracut wich use 'IMPORT{builtin}="kmod'. # pwd /var/tmp/portage/sys-kernel/dracut-024-r4/work/dracut-024 # grep -rl 'IMPORT{builtin}="kmod' ./ # Even 'grep -r kmod' doesn't show any matches related to builtins.
*** Bug 453108 has been marked as a duplicate of this bug. ***
*** Bug 453536 has been marked as a duplicate of this bug. ***
> Although the easiest way would be to depend on ( sys-fs/udev || sys-fs/eudev[kmod] ) May be instead add USE kmod to virtual/udev?
(In reply to comment #10) > > Although the easiest way would be to depend on ( sys-fs/udev || sys-fs/eudev[kmod] ) > > May be instead add USE kmod to virtual/udev? That sounds good. udev maintainers, what do you think?
So what's wrong with udev[-kmod]/eudev[-kmod]? dracut works fine with older versions of udev which has no support for kmod. Also see comment 7. If I'm wrong, please point me to the relevant lines of code.
(In reply to comment #11) > That sounds good. udev maintainers, what do you think? It's done; virtual/udev has IUSE="+kmod"
Please ping me, if eudev eventually follows udev version string format.
The eudev-1_beta2-r2 , the version currently in the tree, reports "196\n" to `udevadm --version`. This seems to be the same format as udev uses, although I only checked against udev-171-r10 . As far as I can tell, dracut had no trouble creating an initramfs with eudev[-kmod]. I haven't had any problems booting with the initramfs either. It would still be nice if the dependency was updated to use virtual/udev .
sys-fs/eudev-1_beta2-r2 +kmod works fine here too with dracut
As far as I could track it, >=sys-apps/systemd-198-r3 installs udev itself rather than relying on sys-fs/udev. This makes it impossible for now to install dracut together with >=sys-apps/systemd-198-r3. Using virtual/udev or listing >=sys-apps/systemd-198-r3 as an alternative to sys-fs/udev would solve this issue. Tested it with a local modified ebuild (requiring virtual/udev instead of sys-fs/udev) and creating an initramfs and booting that one works without issues so far. Log when creating initramfs: I: *** Including module: dash *** I: *** Including module: i18n *** I: *** Including module: kernel-modules *** I: *** Including module: resume *** I: *** Including module: rootfs-block *** I: *** Including module: terminfo *** I: *** Including module: udev-rules *** I: *** Including module: usrmount *** I: *** Including module: base *** I: *** Including module: fs-lib *** I: *** Including module: shutdown *** I: *** Including modules done *** I: *** Installing kernel module dependencies and firmware *** I: *** Installing kernel module dependencies and firmware done *** I: *** Resolving executable dependencies *** I: *** Resolving executable dependencies done*** I: *** Pre-linking files *** I: *** Pre-linking files done *** I: *** Stripping files *** I: *** Stripping files done *** I: *** Creating image file *** I: *** Creating image file done *** I: Wrote /boot/initramfs-3.8.4-1364206803.img: I: -rw------- 1 root root 3209279 25. Mär 11:20 /boot/initramfs-3.8.4-1364206803.img ================================================================= Package Settings ================================================================= sys-kernel/dracut-026-r2 was built with the following: USE="(multilib) optimization -debug -device-mapper -net (-selinux)" ABI_X86="64" DRACUT_MODULES="systemd -biosdevname -bootchart -btrfs -caps -cifs -crypt -crypt-gpg -crypt-loop -dmraid -dmsquash-live -gensplash -iscsi -livenet -lvm -mdraid -multipath -nbd -nfs -plymouth -ssh-client -syslog"
with systemd-200 blocking udev, this also blocks systems without eudev. please convert to virtual/udev asap, regardless whether eudev works or not ...
(In reply to comment #18) > with systemd-200 blocking udev, this also blocks systems without eudev. > please convert to virtual/udev asap, regardless whether eudev works or not I second this. It's annoying.
nothing for udev-bugs@g.o left to do here as dracut is fine with sys-fs/udev :-) CCing eudev and systemd maintainers as dracut is currently broken with them, at least dependency wise
I have personally tested it with systemd-200 and it seems to work fine. I have adjusted the dependency accordingly. + 30 Mar 2013; Mike Gilbert <floppym@gentoo.org> dracut-026-r1.ebuild: + Depend on udev or a recent version of systemd. +
Thanks, Mike. I'll move to virtual/udev after Easter, on Tuesday. I hope Mike's fix solves the problem for now.
All ebuilds since dracut-019-r6 has been switched to virtual/udev. 02 Apr 2013; Amadeusz Żołnowski <aidecoe@gentoo.org> +files/026-0000-fix-version-print.patch, dracut-019-r6.ebuild, dracut-022-r6.ebuild, dracut-023-r4.ebuild, dracut-024-r4.ebuild, dracut-025.ebuild, dracut-026.ebuild, dracut-026-r1.ebuild, +dracut-026-r2.ebuild, dracut-027.ebuild: Switch to virtual/udev in older ebuilds. *dracut-026-r2 (02 Apr 2013) 02 Apr 2013; Amadeusz Żołnowski <aidecoe@gentoo.org> +files/026-0000-fix-version-print.patch, +dracut-026-r2.ebuild: Backporting changes wrt virtual/udev, CONFIG_MODULES and systemd from dracut-027.ebuild. *dracut-027 (02 Apr 2013) 02 Apr 2013; Amadeusz Żołnowski <aidecoe@gentoo.org> +files/027-0001-dracut-functions.sh-support-for-altern.patch, +files/027-0002-gentoo.conf-let-udevdir-be-handled-by-.patch, +dracut-027.ebuild: Version bump. Dracut 027 depends on virtual/udev now and no longer needs CONFIG_MODULES in kernel. [...]
