[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

More info on kernel 2.2 & debian bootdisks woes



Eric Delaunay <delaunay@lix.polytechnique.fr> writes:

> It was using a serial console display.

> Anyway, I'm now using my latest bootdisks merged with a 2.2.0 kernel
> on SparcClassic with linux console (cg3 + monitor) still with no
> success.  It displays the first dialog box (choosing color or
> mononochrome) but the keyboard is not responding at all (not arrow
> keys, no enter, ...) :-( However, I can switch to other VTs (via
> ALT+F?) and in all of them but the first, the keyboard is working
> fine.  Ok, since the second VT is working, I launched dbootstrap in
> it.  It seems to work well: I can do configuring the keyboard,
> partitioning the hard drive, and so on.  I just run in trouble when
> I run a subshell from dbootstrap.  Outputs of the programs I run
> from the shell are going to the second VT as usual, but the shell's
> prompt is not displaying in this VT but in the first one !!!  stderr
> outputs are sent to the first VT as well.  In the first VT I can see
> the following message displayed at ash starting time:

>   sh: can't access tty; job control turned off

> Any hints ?
> Thanks in advance.

I looked into the source code and found that the "dbootstrap" process
was running with stdin/stdout pointing to /dev/tty0, which is causing
problems (could this be a kernel bug?).

To see that this is the problem, do:

  rm /dev/tty0
  mknod /dev/tty0 c 4 1

and kill the dbootstrap process.


The code that is making dbootstrap attach to tty0 is in
/usr/src/boot-floppies/utilities/busybox/init.c:

        default:
                tty = ttyname(0);
                if (tty) {
                        strcpy( console, tty );
                        if (!strncmp( tty, "/dev/cua", 8 ))
                                serial_cons=1;
                }
                else
                        /* falls back to /dev/tty1 if an error occurs */
                        strcpy( console, default_console );

As a hack to fix this, you can disable the "if" part of the above
statement.  (IMHO, it's always wrong to use tty0, since it refers to
the VC that is currently being displayed - if the user switch VC's
then the output would go to the current one.  And ttyname(0) is
returning "/dev/tty0".)

Also, I wonder about the code just above it, it opens /dev/cua0 or
/dev/cua1 if the user specifies a serial console, these devices are
depricated.  If you change those strings to ttyS0 and ttyS1, it may
fix your serial console problems.

Disabling the if part won't break serial consoles - the other parts of
the case statement handle the serial console (although they do so
incorrectly, since cua0 and cua1 no longer exist).


Steve
dunham@cse.msu.edu


Reply to: