Hello, while upgrading from udev-141-r1 to udev-145 I had two problems on my x86_64 system: 1) On 64bit systems the udev ebuild tries to move files from /lib to /lib64 but that is not necessary anymore. The udev build system was changed to install these files directly to /lib64. Because of that there are some warnings while portage runs "src_install". I think the following code has to be removed from the udev-145.ebuild: 168,174d167 < if [[ "$(get_libdir)" != "lib" ]]; then < # we can not just rename /lib to /lib64, because < # make install creates /lib64 and /lib < mkdir -p "${D}/$(get_libdir)" < mv "${D}"/lib/* "${D}/$(get_libdir)/" < rmdir "${D}"/lib < fi 2) Between udev 141 and 145 inotify support of the kernel has become a requirement. I think the ebuild should check if the running kernel has inotify support (problems with cross-compiling?!) because without such a check udev is getting installed but the system will have big problems next time it boots. My systems was not able to start a lot of needed services without a running udev. Another idea: At the moment the ebuild restarts udev. As an addition it could check if udev has been successfully started. If not it should raise a big warning saying that the system should not be restarted before that problem has been solved. Furthermore the official udev README says that udev just needs CONFIG_INOTIFY=y but on my system (2.6.29-gentoo-r6) udev does not run without CONFIG_INOTIFY=y and CONFIG_INOTIFY_USER=y. Thanks. Best regards.
Next time, please open two bugs for two different issues.
@amd64: Can someone with a multilib setup please try if udev emerges fine with the mentioned code removed, as I have only a x86 system.
(In reply to comment #2) > @amd64: > Can someone with a multilib setup please try if udev emerges fine with the > mentioned code removed, as I have only a x86 system. > compiles fine on my multilib system without the mentioned code segment
> 2) Between udev 141 and 145 inotify support of the kernel has become a > requirement. I think the ebuild should check if the running kernel has inotify > support (problems with cross-compiling?!) because without such a check udev is > getting installed but the system will have big problems next time it boots. My > systems was not able to start a lot of needed services without a running udev. > Another idea: At the moment the ebuild restarts udev. As an addition it could > check if udev has been successfully started. If not it should raise a big > warning saying that the system should not be restarted before that problem has > been solved. > Furthermore the official udev README says that udev just needs CONFIG_INOTIFY=y > but on my system (2.6.29-gentoo-r6) udev does not run without CONFIG_INOTIFY=y > and CONFIG_INOTIFY_USER=y. > > Thanks. Best regards. > I've got a likely issue, I get the message "udevd[4071]: error getting buffer for inotify" but everything containing inotify is installed, even the message is the same on different kernels, downgrading to udev-141 solves the problem.
(In reply to comment #3) > (In reply to comment #2) > > @amd64: > > Can someone with a multilib setup please try if udev emerges fine with the > > mentioned code removed, as I have only a x86 system. > > > > compiles fine on my multilib system without the mentioned code segment > If I modify the ebuild to not install to lib but libXX, /lib/udev still stays is it was, so the mentioned code IS needed.
Thanks for adding the kernel checks to the udev ebuild. But I think that the mentioned code segment has to be removed or modified. When using amd64 the function $(get_libdir) returns "lib64" and because of that emerge executes the three commands which are trying to move the contenct of /lib into /lib64. I replaced the mentioned code segment with an "die" command in the udev-145-r1.ebuild, run "emerge -1 udev" and after emerge compiled udev and installed it into ${D} I looked into ${D}: root@abc /var/tmp/portage/sys-fs/udev-145-r1/image $ ls -la drwxr-xr-x 6 root root 49 2009-09-05 17:29:34 . drwxrwxr-x 8 portage portage 136 2009-09-05 17:29:37 .. drwxr-xr-x 3 root root 17 2009-09-05 17:29:34 etc drwxr-xr-x 3 root root 59 2009-09-05 17:29:34 lib64 drwxr-xr-x 2 root root 32 2009-09-05 17:29:34 sbin drwxr-xr-x 5 root root 44 2009-09-05 17:29:34 usr There is no "lib" directory. The first command creates the existing "lib64" directory, the second one tries to move files from "lib" to "lib64" which fails and the third command tries to delete the "lib" directory which fails too. Do I missunderstand something?
zzam: I made your CONFIG_CHECK non-fatal, per the work that ikelos and I have been doing. If the package will build without the options, then they are warnings only. This is needed to build when no kernel sources are present, or they are unconfigured.
As I have no way to check the lib moving code in reality, I adjusted it, that it only gets executed if a directory called lib exists, so it should no longer print warnings.
(In reply to comment #4) > I've got a likely issue, I get the message > "udevd[4071]: error getting buffer for inotify" > but everything containing inotify is installed, even the message is the same on > different kernels, downgrading to udev-141 solves the problem. In case this helps to solve, I had the same message on an amd64 that was newly built using many copied config files from an established amd64. The reference machine is OK with udev-141, -145-r1 and -146, whereas only reverting to -141 was good on the new system. Wondering about the new hardware (Core i7 and SSD), I transplanted the reference system's HDD to the new system. The new system remains stable, and the remaining difference is I can think of is not booting from the SSD. Whetehr that should matter I have no idea. If anyone thinks it will help, I'd be willing to experiment further by involving the SSD in more of the boot process.
(In reply to comment #9) > (In reply to comment #4) Or it's just a configuration error somewhere on the new machine, which would let udev off the hook.
(In reply to comment #10) > (In reply to comment #9) > > (In reply to comment #4) > > Or it's just a configuration error somewhere on the new machine, which would > let udev off the hook. > maybe so, but I have an old machine, and I get the same problem, damn thing used up all my disk space! downgrading to udev-141 solved the issue.
