Bug#121186: boot-floppies: modconf, dbootstrap and bterm don't play well together

[Phil Blundell]

>Perhaps with the above patch we don't need to pursue this avenue
>further?

Guess so.  I'll reassign the bug to bogl and see what Dan has to say.  If it
turns out that there was some good reason for that line to be commented out in
the first place, we might have to make another plan.

p.




-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#121186: boot-floppies: modconf, dbootstrap and bterm don't play well together

[David Kimdon]

Mon, Nov 26, 2001 at 10:58:30PM + wrote:
> In message , 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.cTue 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]

Bug#121186: boot-floppies: modconf, dbootstrap and bterm don't play well together

[Philip Blundell]

In message , 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. 

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

p.



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#121186: boot-floppies: modconf, dbootstrap and bterm don't play well together

[David Kimdon]

Package: boot-floppies
Version: current cvs
Severity: critical
Justification: breaks the whole system

The root problem appears to be that /dev/tty isn't available to processes
running in a bterm.  Perhaps this should be reassigned to bogl-bterm?  It would
be _super_ cool if we can get language chooser to work, but we are already out
of time, fixes needed last week.

1. modconf broken 
When I try to 'Install Kernel and Driver Modules' I get 
/target/usr/sbin/modconf: cannot create /dev/tty: no such device or address
local; release_notes.en: bad variable name
/target/usr/sbin/modconf: cannot create /dev/tty: no such device or address
local; release_notes.en: bad variable name
/target/usr/sbin/modconf: cannot create /dev/tty: no such device or address
local; release_notes.en: bad variable name
etc . . .

2. Shell has no job control
This one isn't all that bad, looks like the same thing, easier to track down
maybe, so I include it.  When I choose 'Execute a shell' I get the message

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

FWIW, both modconf and the shell are invoked simply with system() from within
dbootstrap.  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).

Clues?

-David


-- System Information
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux oink 2.4.9 #1 Mon Sep 24 12:10:45 PDT 2001 i686
Locale: LANG=C, LC_CTYPE=C



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]