Matthijs Kooijman wrote:
after some more fiddling, I can reproduce this after all!
It turns out that the "don't start splashy in initramfs when resume is set"
was preventing me from reproducing the problem.
When splashy is indeed started in initramfs, splashy freezes for me as well.
It turns out that it is not the getpass that freezes, but it's the keyboard
input that gets broken (even before the getpass call).
Some investigation turns out that this freezing happens very close to the
moment where init switches to runlevel 2 and is probably triggered by
something init does. When inserting a sleep at the start and end of my
/etc/init.d/rc script, it turns out that keyboard input is working fine at the
end of the sysinit runlevel (after running all scripts in /etc/rcS.d), but
stops working at the beginning of runlevel 2 (before running any scripts in
/etc/rc2.d).
[...]
There is the following code in the spawn() function, which is responsible for
setting up the environment and forking just before running any command (in
particular, this is executed before running /etc/init.d/rcS):
/*
* In sysinit, boot, bootwait or single user mode:
* for any wait-type subprocess we _force_ the console
* to be its controlling tty.
*/
if (strchr("*#sS", runlevel) && ch->flags & WAITING) {
/*
* We fork once extra. This is so that we can
* wait and change the process group and session
* of the console after exit of the leader.
*/
setsid();
if ((f = console_open(O_RDWR|O_NOCTTY)) >= 0) {
/* Take over controlling tty by force */
(void)ioctl(f, TIOCSCTTY, 1);
dup(f);
dup(f);
Isn't this bug 462626?
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=462626
Needed a change to libdirectfb to get it to work.
Was that change done?
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
