What do those pre-boot kernel messages mean?

Question

Hi,
directly after grub there are some lines printed on the screen (by the ramdisk or kernel?) and I don't know for sure what they mean. Especially the marked ones:
:Loading Initramfs
963: No such process
IP-Config: no device to configure
Waiting 0s before mounting root device...
Kinit: Mounted root (ext3 filesystem) readonly...
Init: version 2.86 booting
So the first one (second line in quote) is really curious. I mean what's he trying to do? He doesn't tell anything but "No such process".   But what process is he looking for and why? The digit 963 is changing. Sometimes it's 963 or 978 or ...
And the third line in the code tells it (the ramdisk?) is trying to configure a networkinterface? I don't want this at all because sometimes I use ethernet and other times (most of the time) wlan with a selfcompiled module... So I manage my network-connection by hand.
Can someone explain me the two lines and how to make them stop? Or point me to a rescource where I can find out about them?
For info: this happens on a vanilla 2.6.27.7.

Answer 1

cengic wrote:
I have also been bothered by this "###: No such process" thing for quite some time. Here is what I've found out.
As byte pointed out it has something to do with the kill line in the init script. That was the first clue where to look. What I've done is to repeat "$(/bin/minips -C udevd -o pid=)" a couple of times before and after the if statement. The result is that the minips reports not only udevd pid but also its own pid. After the udevd is killed minips continues to report its own pid. That is why the number changes all the time. I've tried to repeat the minips behavior outside the init script both in early user space (by passing "break=y" as boot argument) and when system has booted. Unfortunately I wasn't successful.
To get rid of the annoying, irrelevant "###: No such process" messages, until the bug in the minips is fixed upstream, we can patch our /lib/initcpio/init script with the following patch:
132c132
<     /bin/kill -9 ${udevpid}
>     /bin/kill -9 ${udevpid} 2>/dev/null
Weird. The -C flag shouldn't do this, as it's supposed to look at the command name only, not the arguments. Take a look at /proc/$SOME_PROC/stat which is the file it parses. The first two entries are: pid (cmdname).
I can't seem to reproduce this on a real system (running /usr/lib/klibc/bin/minips)