Ian Pratt wrote:
>
>>>>> printed to the console that init is respawning to fast.
>>>>> INIT: Id "1" respawning too fast: disabled for 5 minutes
>>>>> INIT: Id "2" respawning too fast: disabled for 5 minutes
>>>>> INIT: Id "3" respawning too fast: disabled for 5 minutes
>>>>> INIT: Id "4" respawning too fast: disabled for 5 minutes
>>>>> INIT: Id "5" respawning too fast: disabled for 5 minutes
>>>>> INIT: Id "6" respawning too fast: disabled for 5 minutes
>>>>> INIT: no more processes left in this runlevel
>
> Xen currently only starts one console for each guest, tty0. To
> avoid these error messages, comment out the other lines that start
> getty's on other terminals in /etc/inittab.
>
> In any event, these messages are harmless.
Um, I hate to disagree with an actual Xen developer who has
implemented this whole thing, but I believe you are wrong :-)
Those messages are not harmless.
Firstly, if Xen really did provide *only* tty0 - no standard Debian
installation could ever get a console up, since it only starts
consoles on tty1-tty6, not tty0. However, I have booted vanilla Debian
installations under Xen, and there are no error messages of this sort
- so I believe the first console (tty1) is the Xen console, and others
are faked or just don't give an error message.
What these messages really mean (especially the last line, no more
processes left) is that init fails to start any of the gettys. This
usually happens in two different circumstances:
a) INIT is unable to fork *any* processes. This happens with UML when
you have /lib/tls around - forks fail. This should not really happen
with Xen, but if libc is borked, it might. But if this is the case,
then there should be no normal daemon bootup messages either.
b) INIT is unable to open the tty devices. This can ofcourse be
caused by a number of things - having the wrong root partition,
having an empty dev, having devfs mounted without devfsd, having a
broken udev mount or simply by having wrong paths in inittab. We had
one problem where a Debian image downloaded from the net did not have
'tty1' etc. as the device paths, but 'vc/1' instead. (Remember that
devfs is not a good idea with Xen guests.)
So, I guess the original poster needs to check his filesystem image
and that's all - no Xen bug involved in any case.
However, in the case I am actually wrong about this, I already
apologize profusely in advance.
-- Naked
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/xen-devel
|
Home