From the Changelog: 27 Feb 2014; Amadeusz Żołnowski <aidecoe@gentoo.org> dracut-034-r4.ebuild, dracut-036-r3.ebuild, dracut-036-r4.ebuild: The same goes for systemd: blocking 210. 27 Feb 2014; Amadeusz Żołnowski <aidecoe@gentoo.org> dracut-034-r4.ebuild, dracut-036-r3.ebuild, dracut-036-r4.ebuild: udevd has been moved once again to remind us of its existence, thus I'm blocking 210. If I fully understand the problem, we should set $systemdutildir in gentoo.conf even if USE=-systemd (everything just works for me with dracut[systemd] + systemd-210). We cannot use systemd.eclass with sys-fs/udev: 1. sys-fs/udev does not install systemd.pc, thus systemd.eclass cannot query systemdutildir variable from pkg-config. 2. sys=fs/udev is installing systemd-udevd in /lib/systemd, but systemd.eclass defaults to /usr/lib/systemd. Anyway, if we want to allow users to easily switch between openrc and systemd without reemerging of dracut, we should patch dracut like we did it for $rulesdir ($udevaltdirs). =(
Hmm.. Looks like dracut should work fine with sys-fs/udev-210. From dracut: [[ -d $systemdutildir ]] \ || systemdutildir=$(pkg-config systemd --variable=systemdutildir 2>/dev/null) if ! [[ -d "$systemdutildir" ]]; then [[ -d /lib/systemd ]] && systemdutildir=/lib/systemd [[ -d /usr/lib/systemd ]] && systemdutildir=/usr/lib/systemd fi
(In reply to Alexander Tsoy from comment #0) > If I fully understand the problem, we should set $systemdutildir in > gentoo.conf even if USE=-systemd (everything just works for me with > dracut[systemd] + systemd-210). Your initramfs has /lib/systemd/network/99-default.link to control network interfaces? That's the replacement for /lib/udev/rules.d/80-net-name-slot.rules. I wasn't aware any dracut in Portage is capable of handling that yet. Point is, it's not only about the systemd-udevd executable. Not at all.
Yes, dracut is not aware of 80-net-setup-link.rules and 99-default.link
*** Bug 503092 has been marked as a duplicate of this bug. ***
(In reply to Samuli Suominen from comment #2) Ah, thanks for pointing that out and adding it to the ChangeLog. This would be another reason to keep systemd-210 masked IMO.
(In reply to Alexander Tsoy from comment #1) > Hmm.. Looks like dracut should work fine with sys-fs/udev-210. From dracut: > > [[ -d $systemdutildir ]] \ > || systemdutildir=$(pkg-config systemd --variable=systemdutildir > 2>/dev/null) > > if ! [[ -d "$systemdutildir" ]]; then > [[ -d /lib/systemd ]] && systemdutildir=/lib/systemd > [[ -d /usr/lib/systemd ]] && systemdutildir=/usr/lib/systemd > fi Ah. Since udev users have both dirs: /lib/systemd and /usr/lib/systemd, systemdutildir become /usr/lib/systemd
(In reply to Samuli Suominen from comment #2) > (In reply to Alexander Tsoy from comment #0) > > If I fully understand the problem, we should set $systemdutildir in > > gentoo.conf even if USE=-systemd (everything just works for me with > > dracut[systemd] + systemd-210). > > Your initramfs has /lib/systemd/network/99-default.link to control network > interfaces? I don't think it is enough to block >=systemd-210. Moreover, 80-net-setup-link.rules and 99-default.link files in the initramfs create more problems for gentoo users (many users have network drivers compiled into the kernel, see bug 487184) than solve them. Anyway here is a patch adding these files, so we can unblock >=systemd-210 on the next revbump: http://git.kernel.org/cgit/boot/dracut/dracut.git/commit/?id=cd501ff74b29e5a7d197bfe28604be2bcd8824b7
Can you test dracut-9999 with new udevd and systemd? (See c#5 in bug #487184.)
Hmm.. I don't see how your live ebuild could fix the issue with >=sys-fs/udev-210. And there were no issues with sys-apps/systemd regarding the systemd-udevd location.
Not with udevd alone, but it should be OK with udevd+systemd as far as I see, although I cannot test that setup. If it comes to udevd alone, I'm preparing a patch for that.
dracut-9999 should work now with standalone udev, too. Things are going to be fixed in Portage Tree with upcoming dracut-037.
(In reply to Amadeusz Żołnowski from comment #11) > dracut-9999 should work now with standalone udev, too. I know that some openrc users prefer sys-apps/systemd over sys-fs/udev, and some systemd users prefer dracut[-systemd] (currently we have two open systemd-cryptsetup related bugs). With your change combination of dracut[-systemd] + systemd become impossible.
(In reply to Alexander Tsoy from comment #12) > (In reply to Amadeusz Żołnowski from comment #11) > > dracut-9999 should work now with standalone udev, too. > > I know that some openrc users prefer sys-apps/systemd over sys-fs/udev, and > some systemd users prefer dracut[-systemd] (currently we have two open > systemd-cryptsetup related bugs). With your change combination of > dracut[-systemd] + systemd become impossible. There are alternative solutions? Possibly one that upstream could accept in the codebase?
Depending on systemd flag I'm removing/leaving some of dracut modules. What about getting rid of conditional removals at all and systemd flag would just control setting systemd paths? Then user could just add or omit systemd dracut module.
(In reply to Alexander Tsoy from comment #12) > With your change combination of dracut[-systemd] + systemd become impossible. Ah, no. In that case dracut should detect the correct systemdutildir anyway. See the fallback code in comment 1
Yeah, I just tested dracut[-systemd] with systemd and it works. $ grep systemdutildir /usr/lib/dracut/dracut.conf.d/gentoo.conf systemdutildir="/lib/systemd"
So… are all cases fine? If so then I'll commit dracut-9999 as dracut-037 as soon as it is release or as dracut-037_pre earlier.
(In reply to Amadeusz Żołnowski from comment #17) > So… are all cases fine? Currently I don't see any problems.
Fixed in just committed dracut-037.
(In reply to Amadeusz Żołnowski from comment #19) > Fixed in just committed dracut-037. Works fine with udev-211 and systemd-211
