| Summary: | sys-kernel/dracut-022-r4 incorrectly blocks >=sys-fs/udev-187 | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Jan Vesely <jano.vesely> |
| Component: | Current packages | Assignee: | Amadeusz Żołnowski (RETIRED) <aidecoe> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | cybertec.systems, dairinin, dschridde+gentoobugs, dustin, egorov_egor, gentoo, ibuyandtrade0+bugs.gentoo.org, joshua.rich, marduk, Martin.vGagern, naota, negril.nx+gentoo, poncho |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | x86 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
|
Description
Jan Vesely
2012-08-05 13:29:19 UTC
It blocks >=udev-187, because udev maintainer migrated surprisingly to /usr/lib without a notice. It works ok with udev-186 which has used old dirs, but it is no longer in the tree what makes things even more surprising. I will fix dracut ebuilds for that. sry the title is wrong must be typo... I'm currently running (copypasted this time to avoid typos): sys-fs/udev-187-r1 was built with the following: USE="gudev hwdb introspection -doc -keymap -openrc (-selinux) -static-libs" sys-kernel/dracut-022-r3 was built with the following: USE="-debug -device-mapper -net -optimization (-selinux)" DRACUT_MODULES="plymouth -biosdevname -bootchart -btrfs -caps -crypt -crypt-gpg -dmraid -dmsquash-live -gensplash -iscsi -livenet -lvm -mdraid -multipath -nbd -nfs -ssh-client -syslog" and it works ok. Is this setup supposed to work? the Changelog comment gave me the impression that it is not. sry for the type in the title I'm currently running: sys-fs/udev-187-r1 was built with the following: USE="gudev hwdb introspection -doc -keymap -openrc (-selinux) -static-libs" sys-kernel/dracut-022-r3 was built with the following: USE="-debug -device-mapper -net -optimization (-selinux)" DRACUT_MODULES="plymouth -biosdevname -bootchart -btrfs -caps -crypt -crypt-gpg -dmraid -dmsquash-live -gensplash -iscsi -livenet -lvm -mdraid -multipath -nbd -nfs -ssh-client -syslog" Is this supposed to work? The comment and block gave me the impresssion that it is not. (In reply to comment #3) > Is this supposed to work? The comment and block gave me the impresssion that > it is not. Maybe it works for some basic setup, but generally it shouldn't work. udev has been moved to /usr/lib and on Gentoo dracut expects it in /lib, therefore some rules are not copied into initramfs. I am waiting for udev maintainer to explain his surprising move. (In reply to comment #4) > (In reply to comment #3) > > Is this supposed to work? The comment and block gave me the impresssion that > > it is not. > > Maybe it works for some basic setup, but generally it shouldn't work. udev > has been moved to /usr/lib and on Gentoo dracut expects it in /lib, > therefore some rules are not copied into initramfs. I am waiting for udev > maintainer to explain his surprising move. OK, thanks for the explanation. Feel free to close this bug and sorry for the noise. The noise is justified. Don't feel sorry. :-) I'm leaving the bug as is for reference until things are explained. Could we please get sys-fs/udev-186 back, until this issue is solved? It currently prevents me from updating, as it appears impossible to mask >=sys-fs/udev-187, apparently because sys-fs/udisks-1.99.0 requires >=sys-fs/udev-180, and there is no ebuild in Gentoo to satisfy that at the moment. (In reply to comment #7) > it appears impossible to mask >=sys-fs/udev-187 I managed to do just that, by masking >=sys-fs/udev-187 sys-fs/udev-init-scripts >=sys-fs/udisks-1.99.0 and manually downgrading those packages before doing any world updates. That said, I very much second your request: > Could we please get sys-fs/udev-186 back, until this issue is solved? A fix at the distro level of dracut would be nice as well. (In reply to comment #8) > (In reply to comment #7) > > it appears impossible to mask >=sys-fs/udev-187 > > I managed to do just that, by masking > > >=sys-fs/udev-187 > sys-fs/udev-init-scripts > >=sys-fs/udisks-1.99.0 Here I have (# equery depends udisks): gnome-base/gvfs-1.12.3 (udisks ? >=sys-fs/udisks-1.90:2) And the only version >=1.90 in Gentoo is 1.99 which needs =>sys-fs/udev-180. I, too, am unable to update @world because of this block, but using the same entries in package.mask as listed in comment #8, I was able to manually downgrade udev and proceed with the update. I'm sure the udev maintainer moved things for the "usr merge"[1], so I doubt that we'll see anything get moved back. I agree with comment #7, though; the best short-term solution seems to be returning udev 186 to the tree until dracut can be patched. [1] https://fedoraproject.org/wiki/Features/UsrMove I've extracted the dead udev-186.ebuild from CVS and copied it into my overlay. If you'd like to work around this bug simply, you can do this::
layman -a dustin && ln -s /var/lib/layman/dustin/info/package.mask/gentoo-bug-430002 /etc/portage/package.mask/
(In reply to comment #10) > I'm sure the udev maintainer moved things for the "usr merge"[1], so I doubt > that we'll see anything get moved back. I agree with comment #7, though; the > best short-term solution seems to be returning udev 186 to the tree until > dracut can be patched. Yes, this is because of usr merge, but there's a chance udev will be moved back to /lib and the steps will be rethought. The best to do is to get udev 186 and wait until everything is explained. Sorry for the mess. If I look deeply into activities of upstream git systemd dracut I see response activities in dracut-git with filenames systemd! On 2012-08-01 there was a release dracut-023 (In reply to comment #12) > (In reply to comment #10) > > I'm sure the udev maintainer moved things for the "usr merge"[1], so I doubt > > that we'll see anything get moved back. I agree with comment #7, though; the > > best short-term solution seems to be returning udev 186 to the tree until > > dracut can be patched. > > Yes, this is because of usr merge, but there's a chance udev will be moved > back to /lib and the steps will be rethought. > > The best to do is to get udev 186 and wait until everything is explained. > Sorry for the mess. There was a revbump for udev with this comment: 07 Aug 2012; William Hubbs <williamh@gentoo.org> +udev-187-r2.ebuild, udev-9999.ebuild: rev bump to move everything back to /lib/udev from /usr/lib/udev. Also sync live ebuild. I thought it could help this issue, but building initrd with this new udev results in: /init: 124: /init: /lib/systemd/systemd-udevd: not found loadkeys: /us/share/keymaps/i386/qwerty/us.map:4: cannot open include file qwerty-layout using dracut --install /lib/systemd/systemd-udevd fixes the first message but udev is not started. same problem as comment #14, additionally i cannot boot my old initrd anymore. systemd hangs at mounting the filesystems. i get dumped to a rescue shell, as far as i can see udev is not started (but no error messages regarding this). starting systemd-udevd from the rescue shell works fine. using systemd-44-r1, inird generated with dracut (i think with udev 186, but i'm not sure). ok, found the problem .. udev-187-r2 does not install the systemd service files. Instead of rev bumping dracut-023 there seemingly is a migrating plan: zick-zack-panic-attack udev-187-r3.ebuild again install binaries into /usr/lib/udev I see, that udevdir=/lib/udev in /etc/dracut.conf.d/gentoo.conf May be possible to define a variable udevdir in runtime? udevdir=$(pkg-config --variable=udevdir udev) @Egor isn't it both possible and therefore not needed to specify as udev-187-r3 changelog says: "using /usr/lib and allowing packages to put things in /lib for now." (In reply to comment #19) > @Egor isn't it both possible and therefore not needed to specify as > udev-187-r3 changelog says: > "using /usr/lib and allowing packages to put things in /lib for now." Here it is slightly different. What you say, it is necessary to udev could work with binaries and rules from third-party packages that are still putting their files in /lib/udev. Files of the udev will always be in $(pkg-config --variable=udevdir udev) At least with udevdir=/usr/lib/udev in /etc/dracut.conf.d/gentoo.conf I can generate an initrd that boot my system (with udev-187-r3 & dracut-022-r4). I've seen no side-effect for now. 09 Aug 2012; Amadeusz Żołnowski <aidecoe@gentoo.org> dracut-019-r5.ebuild: Remove udev-187 blocker from 019. Fixes bug #430002. 09 Aug 2012; Amadeusz Żołnowski <aidecoe@gentoo.org> dracut-019-r5.ebuild: dracut-019 uses pkg-config at run-time to detect udevdir. Rels bug #430002. *dracut-022-r5 (09 Aug 2012) 09 Aug 2012; Amadeusz Żołnowski <aidecoe@gentoo.org> -dracut-022-r4.ebuild, +dracut-022-r5.ebuild: pkg-config is now used to configure udevdir path in the ebuild. Rels bug #430002. 09 Aug 2012; Amadeusz Żołnowski <aidecoe@gentoo.org> dracut-022-r4.ebuild: Use pkg-config to detect udevdir. Remove udev-187 blocker. |
