# SOLVED udev: "ERROR:  cannot run ipw3945d until sysinit"

## gw

After my last update I get a wlan related error message during boot. These are my installed versions of relevant packages:

net-wireless/ipw3945-1.2.0

net-wireless/ipw3945d-1.7.22-r4

net-wireless/ipw3945-ucode-1.14.2

kernel version: 2.6.20-gentoo-r2

sys-fs/udev-104-r12

This last udev update seems to break the start of ipw3945d, as it ran flawlessly before the update.

The error message is:

```

* Letting udev process events ...

* ERROR:  cannot run ipw3945d until sysinit completes

* ipw3945d will be started in the boot runlevel

```

Later on during the boot process it actually gets started and I have:

```

* Device initiated services: ipw3945d

```

What changed in udev, so that it is no longer able to start the ipw3945 demon, an how can I fix it?

Thanks

gwLast edited by gw on Fri Mar 16, 2007 9:43 am; edited 1 time in total

----------

## mamac

Hi,

I have ipw3945 running on my computer. Everything's ok for me.

First, let's compare versions:

```

* sys-fs/udev

      Latest version available: 104-r12

      Latest version installed: 103

*  net-wireless/ipw3945

      Latest version available: 1.2.0

      Latest version installed: 1.0.5

*  net-wireless/ipw3945-ucode

      Latest version available: 1.14.2

      Latest version installed: 1.13

*  net-wireless/ipw3945d

      Latest version available: 1.7.22-r4

      Latest version installed: 1.7.18

```

How do you start ipw3945?

My output of lsmod (only relevant modules):

```

Module                  Size  Used by

...

ieee80211_crypt_tkip     9664  2

ieee80211_crypt_ccmp     6528  0

ieee80211_crypt_wep     4416  0

ipw3945                96544  1

ieee80211              25288  1 ipw3945

...

ieee80211_crypt         5056  4 ieee80211_crypt_tkip,ieee80211_crypt_ccmp,ieee80211_crypt_wep,ieee80211

...

```

----------

## rafal

I have the same problem. Have you sorted this out ??

What is a solution?

----------

## Waninkoko

 *gw wrote:*   

> What changed in udev, so that it is no longer able to start the ipw3945 demon, an how can I fix it?

 

udev now has coldplug function.

I'm having the same problem but connection works fine (I think...).

----------

## Dumble

I have the same problem too, but the connexion works fine.

It is just an esthetical problem

----------

## drseergio

I confirm, this problem appeared right after an upgrade to the latest udev... Haven't figured out how to get rid of it though...

----------

## Waninkoko

If you want to get rid of this message, try this:

1. Edit /etc/modules.d/ipw3945d and comment all lines.

2. Add ipw3945d to boot runlevel.

Now ipw3945d won't start just after the module is loaded so no error message will appear.

----------

## drseergio

Great, don't forget to run modules-update.

----------

## gw

 *Waninkoko wrote:*   

> If you want to get rid of this message, try this:
> 
> 1. Edit /etc/modules.d/ipw3945d and comment all lines.
> 
> 2. Add ipw3945d to boot runlevel.
> ...

 

This actually solves the problem, though I did not understand through what modification of udev the initial error was triggered. I also tried several coldplug related settings in /etc/conf.d/rc but without success.

gw

----------

## broken_chaos

As near as I can tell, there were only two files changed between 104-r11 and 104-r12... One is udev-start.sh, and the other modprobe.sh (in addition to a modification to the ebuild, but that has to do with chroots, nothing else).

I'm almost certain the changes to udev-start.sh did not cause this at all. All of them appear to either be fixes to work with non-bash shells, or fixes to help with a fbsplash error (overwriting the splash image), and none appear to be severe enough to cause this. (I've got a diff created by this command: diff -uN /usr/portage/sys-fs/udev/files/udev-start-104-r10.sh /usr/portage/sys-fs/udev/files/udev-start-104-r12.sh)

I'm a little less clear of the impact of the modprobe.sh changes, since they seem to be towards the same goal - non-bash shells, and fbsplash quiet mode - but they're a little more complex. (My diff was created by this command: diff -uN /usr/portage/sys-fs/udev/files/modprobe.sh /usr/portage/sys-fs/udev/files/modprobe-104-r12.sh)

I'll play with it a bit more, though, and see if I can get it back to working the way it 'should'.

----------

## broken_chaos

Ok, I solved this!

First, the error has always existed. The changes to udev to make it work with a silent fbsplash simply made udev a little *too* verbose in printing errors to console. The solution is to modify /etc/modules.d/ipw3945d to not print any errors and return a successful exit code.

Here's the modified file (I'll make a bugzilla bug on it shortly):

```
install ipw3945 /sbin/modprobe --ignore-install ipw3945; sleep 0.5; /etc/init.d/ipw3945d start > /dev/null; exit 0

remove ipw3945 /etc/init.d/ipw3945d stop > /dev/null; /sbin/modprobe -r --ignore-remove ipw3945
```

The drawback is now that we won't know if it fails or succeeds when running manually, but it should almost never *be* run manually (i.e. modprobe ipw3945 or modprobe -r ipw3945).

----------

## gw

 *broken_chaos wrote:*   

> Ok, I solved this!
> 
> First, the error has always existed. The changes to udev to make it work with a silent fbsplash simply made udev a little *too* verbose in printing errors to console. The solution is to modify /etc/modules.d/ipw3945d to not print any errors and return a successful exit code.
> 
> 

 

Thanks a lot for sorting this out! This really explains what was going on.

gw

----------

## pacho2

 *broken_chaos wrote:*   

> Ok, I solved this!
> 
> First, the error has always existed. The changes to udev to make it work with a silent fbsplash simply made udev a little *too* verbose in printing errors to console. The solution is to modify /etc/modules.d/ipw3945d to not print any errors and return a successful exit code.
> 
> Here's the modified file (I'll make a bugzilla bug on it shortly):
> ...

 

Can you please post a link with the bug report?

Thanks a lot  :Smile: 

----------

## broken_chaos

 *pacho2 wrote:*   

> Can you please post a link with the bug report?

 

It's bug #171295.

----------

## pacho2

OK, thanks for the link  :Smile: 

----------

## fbcyborg

 *broken_chaos wrote:*   

> Ok, I solved this!
> 
> First, the error has always existed. The changes to udev to make it work with a silent fbsplash simply made udev a little *too* verbose in printing errors to console. The solution is to modify /etc/modules.d/ipw3945d to not print any errors and return a successful exit code.
> 
> Here's the modified file (I'll make a bugzilla bug on it shortly):
> ...

 

Hello! 

I tried to modify /etc/modules.d/ipw3945d file as described above, but I still get that error. What's wrong?

I didn't do update-modules. If I try, it suggest me the following:

```
* Warning: the current /etc/modules.conf has not been automatically generated

 * Use "update-modules force" to force (re)generation

```

What should I do?

Thanks.

EDIT: finally I did 

```
update-modules --force
```

 All works fine now. Thanks.

----------

## user118696

If you modify /etc/modules.d/ipw3945d from this :

```
install ipw3945 /sbin/modprobe --ignore-install ipw3945; sleep 0.5; /etc/init.d/ipw3945d start
```

to that :

```
install ipw3945 /sbin/modprobe --ignore-install ipw3945
```

and do the following :

```
rc-update add ipw3945d default
```

WHY is udev still trying to start the daemon at an early stage in the boot process? Where is it started from?

----------

## broken_chaos

 *muaddib wrote:*   

> If you modify /etc/modules.d/ipw3945d from this :
> 
> ```
> install ipw3945 /sbin/modprobe --ignore-install ipw3945; sleep 0.5; /etc/init.d/ipw3945d start
> ```
> ...

 

Did you run modules-update? And if you're going to do it that way (not started by modprobe at all) just remove the entire /etc/modules.d/ipw3945d file instead...

----------

## user118696

 *broken_chaos wrote:*   

> Did you run modules-update?

 

I did.

 *broken_chaos wrote:*   

> And if you're going to do it that way (not started by modprobe at all) just remove the entire /etc/modules.d/ipw3945d file instead...

 

Removing this file wouldn't change anything. It's just a configuration file. Isn't it?

----------

## broken_chaos

 *muaddib wrote:*   

> Removing this file wouldn't change anything. It's just a configuration file. Isn't it?

 

It's the configuration file that causes udev to try to start the daemon at boot. As I noted, it's all just done by modprobe trying it and baselayout making a note that it tried (and failed) to start.

So yes, it actually would change things. Assuming you ran update-modules afterwards, since that 'applies' the changes.

----------

## cipherus

i had this rather annoying problem too (i'm a neat freak).  what i did was just remove /etc/modules.d/ipw3945d altogether because you don't need this daemon process to be modprobed or dealt with by udev at all, just the device itself (ipw3945).  i think it's an error with the ebuild to even add this file.

do `rc-update add ipw3945d boot` and all your wifi loads and works automatically anyway.  although i prefer to bring it up manually with `/etc/init.d/ipw3945d start` whenever i feel like enabling wifi because i hardly ever use wifi and when i do i change the drivers i'm using a lot.  ipwraw ftw.

----------

## jan_miro

Hey,

What are your ieee settings in your kernel - are they fixed ?

If they are fixed chenge to module 

-> Netwrking -> Wireless -> ??

In my case it helped ... my ipw3945 is started via initscripts and not via udev

Miro

----------

