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

[Luis Mondesi]

On Tue, Jul 29, 2008 at 12:11 PM, Matthijs Kooijman <matthijs at stdin.nl> wrote:
> 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?


Awesome stuff Matthijs. I'll definitely look into this closer because
now that we chroot to the real root filesystem early in initramfs, I
don't think we need to chvt to vt 8 any more. The other reason to use
tty8 was for it not to show any text before gdm/kdm/xdm/X started, but
we can go around this by simply clearing the content of tty1 from the
splashy script before we exit.

Whoever wants to troubleshoot their system will probably boot in
single-user-mode or Splashy will need to allow autoverbose again.

Good job finding this. You're my hero!

-- 
----)(-----
Luis Mondesi
Maestro Debiano

----- START ENCRYPTED BLOCK (Triple-ROT13) ------
Gur Hohagh [Yvahk] qvfgevohgvba oevatf gur fcvevg bs Hohagh gb gur
fbsgjner jbeyq.
----- END ENCRYPTED BLOCK (Triple-ROT13) ------