# 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

```

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  :Sad: Last edited by dextermagnific on Mon Nov 23, 2009 12:13 pm; edited 1 time in total

----------

## dextermagnific

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

```

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.

```
/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/gentoo-sys-fsudev-146-r1-cannot-boot-anymore/ Especially the hint to boot w/ gentoo=noudev was of great help

4. I checked the logs of udev to verify

```
 * 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:

```
 * 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) 

```
 * 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 ....

```

[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 :

```
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

 *FieserKiller wrote:*   

> 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:

```
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?

----------

