You are not logged in.
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.
Offline
First of all: lots of people get that output and it's completely harmless.
I think the first line is caused by http://projects.archlinux.org/?p=mkinit … =init#l129 (the 'kill' line), although I'm not really sure why.
The second line is about kernel network support. You didn't indicate that your root filesystem is on a NFS share, so there's nothing to be done.
Last edited by byte (2008-12-05 09:00:05)
1000
Offline
The second line is ipconfig, which is included in kinit: you can pass a command line argument to the kernel, that will cause kinit to configure your network and mount an nfs share. However, as you don't do that, kinit simply states that there is nothing to do. This can be ignored.
I am confused about the first one: we try to kill udevd so kinit can clean up the rootfs (effectively freeing the memory used by the initramfs). The code looks like this:
udevpid=$(/bin/minips -C udevd -o pid=)
if [ -n "${udevpid}" ]; then
/bin/kill -9 ${udevpid}
/bin/sleep 0.01
fi
I have no idea how the message could be caused by that: If there is no udevd process, then nothing is done, otherwise an existing process is killed.
Offline
If booting without a framebuffer I got the following output in addition to the "no such process" thing: "Kernel alive" and some time later "Kernel is really alive". Both message show up at the bottom of the screen.
Offline
hmm sometimes there are also two lines like:
...
952: No such process
953: No such process
...
And very seldom there's no such line. Could you tell me in which package this check you showed is contained, so I can further debug this issue?
Offline
You should really not worry about any of this stuff. As for the no-such-process thing, that may be a legitimate bug, but the ip-config part you can safely ignore.
One thing that no one gets is that whatever happens in early-userspace simply doesn't matter to the rest of your machine. The early-userspace IP-Config call has no effect on you networking.
Details: kinit has the capability to setup a network device to enable root filesystems on NFS and the like. It finds no arguments indicating you want a network device loaded in early-userspace, so outputs a message saying that it is doing nothing.
Edit gah, should have read brain0's reply
Offline
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
Offline
I 'solved' it by putting a half-second sleep before "udevpid=$(/bin/minips -C udevd -o pid=)".
Last edited by byte (2008-12-16 21:32:45)
1000
Offline
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)
Offline
I could reproduce it every time here.
$udevpid contained three values, for three udevd's. I added several long sleeps and also a complete minips listing to /lib/initcpio/init, and yes, there were multiple udevd processes. One with a rather low PID and two with much higher, very close to each other, PIDs.
1000
Offline
Hi, yes sometimes this msg appears, because udevd forks a process and finish very quickly.
putting a /bin/minips -f -C udevd you can see these udev process and the parent.
UID PID PPID C STIME TTY TIME CMD
0 25 1 - - 0,0 00:00:00 [udevd]
0 343 25 - - 0,0 00:00:00 [udevd]
Offline
Now I am getting such error messages at the boot time after the " Loading Initramfs" line and the error number is not the same every time, the numbers I got were 480 / 488 / 489 /490 /499. Apart from this error, system is working fine. I could not find this error in any of the log files. Arch is running on Acer 291Lci laptop. I put this for information to find the reason for such errors and guidance to eliminate this.
I tried the patch but still getting nnn: no such process error (nnn : error numbers still varies as i mentioned)
http://bugs.archlinux.org/task/13106?
Last edited by kgas (2009-02-28 17:51:50)
Offline
kgas: Rember to regenerate the initcpio when you apply the patch.
By the way. The kernel gets updated often so that I've stopped removing the messages since they are harmless. Instead I'm ignoring them since the cause has been clarified here.
Offline