[Splashy-devel] Bug#492643: Can reproduce!

[Matthijs Kooijman]

Package: splashy
Version: 0.3.11-1

Hi,

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).

It turns out that removing the splashy_chvt 8 call near the end of
/usr/share/initramfs-tools/scripts/init-top/splashy solves my problems:
keyboard input remains functional during the entire boot process. This made me
suspect that init somehow forces the current vt back to 1 when switching to
runlevel 2, (which is then not visible on the screen since directfb writes
directly on the framebuffer, but is enforced on the keyboard input side of
things).

This is also confirmed by the fact that, when the chvt 8 is present in
initramfs, after the full boot, I end up with an empty screen. Pressing alt-F1
changes nothing, but pressing enter gives me tty1. This might also be splashy
(or the splashy initscript) that switches back to vt1 after it exits (does
it?).

However, when I quit splashy before init switches to runlevel 2 (either during
initramfs or during sysinit runlevel), I end up on vt8, even after init enters
runlevel 2. This seems to be contradictory to my above theory.

I've also spent some timing digging around in init's sources, but I can't seem
to find anything it does between the sysinit runlevel and runlevel 2 that
could cause something like this.

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);
                        }

I'm not sure what it does, but it would be weird that something that happens
at the beginning of the sysinit level would break things (one would expect
that something at the beginning of runlevel 2 would break it). On the other
hand, it could be that this code actually makes things work, or that some code
in the else branch of the above if breaks it (though it looks innocent
enough).

So, a solution seems to be to not change to vt8 in initramfs, but unless we
found out what happens exactly, it might not be a good idea to just remove
that and see what happens. Also, since splashy tells libdirectfb to use vt8
(according to Luis), this might need changing as well (though it does seem to
work with just removing the chvt 8, at least on my system).

I'm out of time for now, Jonas, could you see if removing the splashy_chvt 8
works for you as well?

Gr.

Matthijs
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.alioth.debian.org/pipermail/splashy-devel/attachments/20080729/e57f8e5d/attachment.pgp