udev won't start because of inotify support [SOLVED]

[dextermagnific]

Hi,

I recently upgraded my udev to version 147 and since It won't start saying that it fails to initialize inotify
Inotify support is compiled into my kernel and previous versions of udev worked fine

running udevd --debug shows

Code: Select all

udev_watch_init : inotify_init failed : function not implemented
error initializing inotify

Wihtout udev I can't access my home partition, can't enable networking, can't do anything ! even /dev/tty* login screens are not available except one !
My system is completely useless

[dextermagnific]

I tried to recompile udev and here is what I get :

Code: Select all

udev/udev-watch.o : in function udev_watch_init :
udev-watch.c:(.text+0x632): warning : inotify_init1 is not implemented and will always fail

Don't know why this happens

How can I recover a minimal /dev structure so that I can have network access (ethX devices) and be able to downgrade udev ?

[dextermagnific]

OK here is how I solved the problem :

1. buy an empty CD
2. burn the minimal gentoo install iso
3. boot on CD and mount your hard drive root partition somewhere
4. chroot to that directory
6. load your profile : source /etc/profile
5. downgrade udev to version 146-r1

seems like there is a problem with version 147

[WetSpot]

dextermagnific,
Thanks for the heads up about a possible problem udev-147+

Here's how I solved the same problem you had.

Code: Select all

/usr/portage/profiles/package.mask
>=sys-fs/udev-147

Re-emerging (downgraded) udev from udev-149 to udev-146.2 then restarting udev worked like a charm.

[VoidMage]

That problem is only due to your kernel/glibc being too old
(at least for x86/amd64, IIRC it seems on alpha it's still unimplemented).

[s3ta]

Hi,

I'm still running into the same prob -

History:
1. Systemupgrade on a system which hasn't been updated for a while. (including upgrade to a current kernel - 2.6.31-r10)
2. After the upgrade I got these probs (udev doesn't start - complains about inotify)
3. Started googling - Found http://blog.someone.exofire.net/2009/11 ... t-anymore/ Especially the hint to boot w/ gentoo=noudev was of great help
4. I checked the logs of udev to verify

Code: Select all

 * Found kernel object directory:
 *     /lib/modules/2.6.20-gentoo-r8/build
 * Found sources for kernel version:
 *     2.6.20-gentoo-r8
 * Checking for suitable kernel configuration options...
 *   CONFIG_SIGNALFD:    is not set when it should be.
 *   CONFIG_SYSFS_DEPRECATED:    should not be set. But it is.

5. So I checked the kernel and re-emerged udev, checked the log - the warning was gone - reboot - same problem:

Code: Select all

 * Your kernel version (2.6.31-gentoo-r10) is new enough to run udev-149 reliably.

 * Determining the location of the kernel source code
 * Found kernel source directory:
 *     /usr/src/linux-2.6.31-gentoo-r10
 * Found kernel object directory:
 *     /lib/modules/2.6.31-gentoo-r10/build
 * Found sources for kernel version:
 *     2.6.31-gentoo-r10
>>> Unpacking source...

6. I Found this post here and I have been downgrading to udev to: Installed versions: 146-r1!t(11:53:24 17.03.2010)(devfs-compat -extras -selinux)

Code: Select all

 * udev-146 does not support Linux kernel before version 2.6.25!
 * For a reliable udev, use at least kernel 2.6.27

 * Your kernel version (2.6.31-gentoo-r10) is new enough to run udev-146 reliably.

 * Determining the location of the kernel source code
 * Found kernel source directory:
 *     /usr/src/linux-2.6.31-gentoo-r10
 * Found kernel object directory:
 *     /lib/modules/2.6.31-gentoo-r10/build
 * Found sources for kernel version:
 *     2.6.31-gentoo-r10
>>> Unpacking source...

7. Still the problem occurs - the VoidMage told us glibc/kernel were old - they aren't on my sys ....

Code: Select all

[I] sys-libs/glibc
     Installed versions:  2.10.1-r1(2.2)!s(17:23:17 09.03.2010)(gd nls -crosscompile_opts_headers-only -debug -glibc-omitfp -hardened -multilib -profile -selinux -vanilla)

and kernel version 2.6.31-gentoo-r10 (gentoo-sources)

Any Ideas?

[VoidMage]

Here "kernel" meant also "kernel headers".

[imanassypov]

~amd is also having udev above v 146 broken. Masking as suggested above resolved the issue.

[nanodust]

masking worked - system's back !

thank you !

[Plague.CZ]

Sorry for reopening, but udev-179 is stable now (x86) and the system is trashed (newest stable system). Can anybody confirm this or dis I mess something up?

[Whitewolf Fox]

I'm currently running into exactly this Problems with a fresh setup - masking + re-emerging didn't work. So I'm confirming.

[Whitewolf Fox]

OK, on second sight I have to admit that this doesn't seem like a Bug:

When I Googled recently, there are many issues for Debian, Ubuntu, ARCH Linux, etc. with the same problem. It seems as if the capability for inotify within a kernel has always been strongly recommended and with the new udev Version it became a requirement instead of a recommendation.

After enabling of :

Code: Select all

File systems  --->
     [*] Dnotify support
     [*] Inotify file change notification support
     [*] Inotify support for userspace

within the Kernel config udev worked perfectly.

So it seems more like a not fulfilled requirement but a bug to me.

[depontius]

Just getting onto this thread because I'm seeing things about "udev" and "extras" as well as HAL going away with newer xorg-server.

I would call this a bug, as well. I can't name one now, but I know that there are other packages which query the kernel config, and error out with a message if necessary. One just came up... sys-fs/openafs will not install if the Linux kernel afs support is selected. (You can use one or the other, but not both, and I'm under the impression that the kernel afs isn't really usable, anyway.) The fly in the ointment is that I believe the ebuild checks the current kernel tree, as pointed by /usr/src/linux. That may or may not correspond to the kernel you're currently running. (IMHO they should look for /proc/config.gz first.)

[FieserKiller]

Just a short info for everyone who runs into that problem:

1. You can boot with kernel option gentoo=noudev fine while udev is wrecked
2. reemerge udev, look portage output for some kernel config warnings, resolve them, let udev compile
3. At least I had to reemerge glibc to make udev work again

you can check anytime with udevd --debug if udev is working again or not.

hope that helps..

[metalim]

Same here. After new glibc was built with --nodep (I was fighting the system for three days after 2 years of no updates) and old linux-headers, I was getting non-working kernel/udev combination.
After re-emerging glibc and rebuilding kernel, error was gone.

[raygun]

1. You can boot with kernel option gentoo=noudev fine while udev is wrecked

This no longer appears to be the case. I changed my grub entry to read:

Code: Select all

kernel (hd0,0)/boot/vmlinuz-2.6.38-gentoo-r6 root=/dev/sda3 gentoo=noudev

but the system still boots with the broken udev, and thus as a mostly unusable system. Is this the correct syntax for the noudev kernel option?

I found an archived 2004 edition of the Gentoo udev guide which mentions the gentoo=noudev boot option, but the most current version of the Gentoo udev guide does not mention this kernel option anywhere, so my guess is that it's not supported anymore.

However, since udev is failing, I need to boot my system without it so that I can rebuild it (and possibly glibc, as suggested). What is the current mechanism for this?