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 @@ close(ptyfd); setsid(); - /*ioctl(ttyfd, TIOCSCTTY, (char *)0);*/ + ioctl(ttyfd, TIOCSCTTY, (char *)0); dup2(ttyfd, 0); dup2(ttyfd, 1); dup2(ttyfd, 2); > > >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 further? -David -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
