Bug#121186: boot-floppies: modconf, dbootstrap and bterm don't play well together
Mon, Nov 26, 2001 at 10:58:30PM +0000 wrote:
> In message <[🔎] E168FqK-0007t2-00@oink>, David Kimdon writes:
> >The root problem appears to be that /dev/tty isn't available to processes
> >running in a bterm.
> Well, I've spent most of this evening just trying to get i18n'd boot-floppies to start on my i386 box. Turns out that the 2.2.19 kernels don't seem to be able
> to do fbcon on my video card (an nVidia Geforce2), and this is a completely
> fatal situation -- bterm just prints "/dev/fb0: no such device" and you never
> get anywhere at all. I'll try to do something about that in a minute.
> As to the original bug, I think the problem is that bterm is failing to set
> a controlling tty up. Can you try uncommenting the TIOCSCTTY call in bterm.c::spawn_shell() and see if that makes any difference for you? I don't
> quite understand what makes it work in the non-i18n case, but still.
Neat, that fixed it. Specifically:
--- bogl-0.1.7/bterm.c Sun Mar 11 16:31:41 2001
+++ bogl-0.1.7.fixed/bterm.c Tue Nov 27 00:05:27 2001
@@ -117,7 +117,7 @@
- /*ioctl(ttyfd, TIOCSCTTY, (char *)0);*/
+ ioctl(ttyfd, TIOCSCTTY, (char *)0);
> >I tried a few hacks like removing the /dev/tty redirection from
> >modconf (complete failure), and redirecting to other tty's (sort of worked, but
> >isn't really acceptable since user would have to do alt-f4 to use modconf, and
> >then alt-f1 when it is finished).
> Did you try /dev/tty0? That's still a hack, but it might be a good enough
> workaround to get us out of this particular hole.
There was one thing I tried, maybe it was that, where I got modconf to
appear on a separate vt, but it wasn't accepting any input from me.
Perhaps with the above patch we don't need to pursue this avenue