I came aross the perl script (ttyalloc ?))posted by Jan "Bulb" Hudec on 2003-01-28 on the user-mode-linux-devel forum. This script sets aside a tty for umlgdb to use. This seems to have taken care of the 'input' issues I have referred to in my original post. UML runs just fine in the window assigned by this perl script. I can login and do whatever.
However, the issue I am now running into is that I do not know how (and where) to get to the gdb prompt. The umlgdb script kicks of gdb and passes to it the tty set aside by the ttyalloc script. gdb uses this tty for uml to run. If I send a SIGINT to the kernel process (thread) of the UML, (Per Jeff Dike's instructions to debug uml in skas mode), the uml session just seems to hang. Any idea what I should be doing now to get to the ? Thanks a lot for the responses so far. I have learnt from them many things I did not know earlier. Murthy Andukuri --- Rob Landley <[EMAIL PROTECTED]> wrote: > On Sunday 27 November 2005 11:31, Blaisorblade > wrote: > > On Sunday 27 November 2005 05:48, murthy andukuri > wrote: > > > I can bring up a uml session successfully when > > > invoking from command line. and can also bring > up a > > > uml session successfully from within a gdb > (following > > > instructions from the 'how to'). However, I am > having > > > trouble being able to input login info to the > same uml > > > when started thru umlgdb. All of these attempts > are > > > with the skas patch on the host. host and guest > are > > > both 2.6.12.1. > > > > > > can somebody please tell me what I am missing ? > More > > > details below. > > > > A workaround (for sure) is to make UML open its > console not on fd:0,fd:1. > > Either you move the login prompt away from tty0 > and to ttyN, or you use > > con0=xterm (or con0=your console channel). > > I wanted to run a script that did UML with the > output piped to "tee". > Unfortunately, the standard "tee" will stop > outputting to a target if it ever > gets pipe full even once, and with the disk I/O > problem you have when /tmp > isn't tmpfs, that would usually happen to the xterm > after about 5 minutes. > > So what I wound up doing was: > > (./build.sh > out.txt 2>&1 &) && tail -f out.txt > > Except that this didn't work because the detached > ./build.sh would die as soon > as it ran UML, because if UML gets EOF on stdin on > its way up, it refuses to > run. > > My solution? > > (cat /dev/zero | ./build.sh > out.txt 2>&1 &) && > tail -f out.txt > > This works fine as long as nothing ever tries to > read from stdin. (When I > have a config file wrong and busybox/uclibc/linux > runs "make oldconfig" it > spits nulls and ctrl-g to the output file in a tight > loop until it fills up > the disk. But oh well...) > > Rob > > > I don't know for sure, but the problem is likely > to be this: > > - reading from stdin *requires* that you're > passing UML a real tty, not a > > normal fd. > > Nope, /dev/zero works fine for me. > > > - umlgdb redirects UML stdin to a pipe > > It probably closes stdin. > > > - things don't work. > > UML dies if stdin gives EOF on startup. (I vaguely > remember catting /dev/null > to it instead of /dev/zero and it didn't work. This > was a while ago so I'm > guessing...) > > > > Thru umlgdb, I am able to get the uml boot up to > start > > > in the right tty (set as a part of the initgdb > method > > > in umlgdb). But, if I type the user name at the > login > > > prompt, I get the response > > > > It's not succeeding in catching the input, but > it's only throwing out > > messages. > > UML's stdio console handling has always been fairly > brittle. I banged on > stdout, but never got around to poking at stdin > because I could work around > it. > > > > In the bootup log messages, I see a few > 'TIOCSCTTY > > > failed', errno =1. . . > > > > That's the "it requires a tty, not a pipe" thing. > > It does not. Try the /dev/null thing with init > being some sort of script that > echoes "hello world" or some such. > > > I guess it's parsing /etc/inittab, even if I don't > understand how... > > Possibly the busybox inittab? The format for that > is different... > > > anybody looking for /dev/ttyvc/0 is seriously > confused... probably it's > > splicing together /dev/tty and some field (first > or last one) in > > /etc/inittab (which is a bit buggy anyway). > > That's a mixture of the devfs and non-devfs > syntaxes. Devfs has /dev/vc/0 and > a real system has /dev/tty0. > > Rob > -- > Steve Ballmer: Innovation! Inigo Montoya: You keep > using that word. > I do not think it means what you think it means. > > > ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do > you grep through log files > for problems? Stop! Download the new AJAX search > engine that makes > searching your log files as easy as surfing the > web. DOWNLOAD SPLUNK! > http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click > _______________________________________________ > User-mode-linux-user mailing list > User-mode-linux-user@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/user-mode-linux-user > __________________________________ Yahoo! Music Unlimited Access over 1 million songs. Try it free. http://music.yahoo.com/unlimited/ ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click _______________________________________________ User-mode-linux-user mailing list User-mode-linux-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/user-mode-linux-user
