I had a closer look at the source, and suspect a patch like this might
solve it, by running all scripts sequencially if the tty is strange.
Index: startpar.c
===
--- startpar.c (revision 1898)
+++ startpar.c (working copy)
@@
severity 584102 serious
severity 583562 serious
forcemerge 584102 583562
found 584102 2.88dsf-5
found 584102 2.86.ds1-61
thanks
I believe this issue is RC and severity serious, but not critical, as
a workaround is known (disable parallel booting). It should
definitely be fixed before Squeeze is
stty -a doesn't output anything when it's being launched via init
scripts at boot time. It exits with exit code 1.
The system boots properly with startpar enabled when call to
tcgetattr() isn't a fatal error - as I've written before.
Peter, perhaps we could briefly describe the variable in your
[Bartosz Pierzchala]
stty -a doesn't output anything when it's being launched via init
scripts at boot time. It exits with exit code 1.
Right. So no tty available. :)
The system boots properly with startpar enabled when call to
tcgetattr() isn't a fatal error - as I've written before.
I
[Petter Reinholdtsen]
Why do OpenVZ not provide a working tty to sysvinit/startpar?
I very much welcome someone with OpenVZ knowledge to answer this one,
to know why startpar fail with OpenVZ.
I had a look at the startpar source, I suspect this code in startpar.c
is the failing one:
if
[Bartosz Pierzchala]
There's also one note that adding:
CONCURRENCY=none
to /etc/default/rcS
makes the system boot properly.
This indicate that the problem is with startpar, and not with sysvinit
as such. Perhaps it should be changed to run sequencially if the tty
is broken? Patches
Package: sysvinit
Version: 2.88dsf-5
After debootstraping testing/squeeze there's a problem when trying to
start it under OpenVZ. init starts but the rc scripts fail to properly
setup environment (run scripts from runlevel S and runlevel 2).
OpenVZ's vzctl enter VEID dies with the following error
7 matches
Mail list logo
