On Thu, May 19, 2005 at 02:26:11PM +0800, Yi Shu LIU wrote:
> Hi, 
> 
> I tried to connect a UML with the host linux machine through tty and
> succeed, but then when I tried to boot another UML to play as the slave end,
> I failed. I hope some of you could give me some guide.

I recently wrote this up for the UML Book (TM).  See below.

                                Jeff

[BODY] This serial line will be constructed from a host psuedo-terminal,
namely a Unix98 pts device.  Pseudo-terminals on Unix are pipes -
whatever goes in one end comes out the other, possibly with some
processing in between, such as line editing.  This processing is what
distinguishes pseudo-terminals from normal Unix pipes.  The end that's
opened first is the pty end, and it's the master side - the device
doesn't really exist until this side is opened.  So, the UML to which
we are going to log in will open the master side of the device, and
later, the slave side will be opened by the other UML by us logging in
over it.

[BODY] We are going to make both ends of the device appear inside the UMLs as
normal, hardwired, terminals.  One UML is going to run a getty on it,
and we run run a screen session inside the other UML attached to its
terminal.

[BODY] To get started, we need to identify an unused terminal in both UMLs.
This can be done in one of two ways - read /etc/inittab to find the
first terminal which has no getty running on it or run ps to discover
the same thing.  The relevant section of inittab looks like this:

[CTD1] # /sbin/getty invocations for the runlevels.
[CTD] #
[CTD] # The "id" field MUST be the same as the last
[CTD] # characters of the device (after "tty").
[CTD] #
[CTD] # Format:
[CTD] #  <id>:<runlevels>:<action>:<process>
[CTD] 0:2345:respawn:/sbin/getty 38400 tty0
[CTD] 1:2345:respawn:/sbin/getty 38400 tty1
[CTD] 2:2345:respawn:/sbin/getty 38400 tty2
[CTD] 3:2345:respawn:/sbin/getty 38400 tty3
[CTD] 4:2345:respawn:/sbin/getty 38400 tty4
[CTD] 5:2345:respawn:/sbin/getty 38400 tty5
[CTD] 6:2345:respawn:/sbin/getty 38400 tty6
[CTD] 7:2345:respawn:/sbin/getty 38400 tty7
[CTDX] c:2345:respawn:/sbin/getty 38400 ttyS0

>From this, it appears that tty8 is unused.  ps confirms this:

[CDT1] UML1# ps uax | grep getty
[CDT] root       153  0.0  0.3  1084  444 tty1     S    14:07   0:00 
[CDT]      /sbin/getty 38400 tty1
[CDT] root       154  0.0  0.3  1088  448 tty2     S    14:07   0:00 
[CDT]      /sbin/getty 38400 tty2
[CDT] root       155  0.0  0.3  1084  444 tty3     S    14:07   0:00 
[CDT]      /sbin/getty 38400 tty3
[CDT] root       156  0.0  0.3  1088  448 tty4     S    14:07   0:00 
[CDT]      /sbin/getty 38400 tty4
[CDT] root       157  0.0  0.3  1088  452 tty5     S    14:07   0:00 
[CDT]      /sbin/getty 38400 tty5
[CDT] root       158  0.0  0.3  1088  452 tty6     S    14:07   0:00 
[CDT]      /sbin/getty 38400 tty6
[CDT] root       159  0.0  0.3  1088  452 tty7     S    14:07   0:00 
[CDT]      /sbin/getty 38400 tty7
[CDT] root       160  0.0  0.3  1084  444 ttyS0    S    14:07   0:00 
[CDTX]      /sbin/getty 38400 ttyS0

This is the same on both UMLs, as you would expect, so I will use tty8
as the serial line on both UMLs.  

[BODY] The first thing we need to do is plug in a properly configured tty8
to the master UML, the one to which we will be logging in.  This is
done with uml_mconsole on the host, configuring con8, which is the
mconsole name for the device that is tty8 inside UML:

[CDT1] % uml_mconsole debian2 config con8=pts
[CDTX] OK 

Now we need to know what the other end of the pts device is, since
that's determined dynamically for these devices:

[CDT1] % uml_mconsole debian2 config con8
[CDTX] OK pts:/dev/pts/28

This tells us how to configure con8 on the slave UML:

[CDT1] host% uml_mconsole debian1 config con8=tty:/dev/pts/28
[CDTX] OK 

[BODY] Here we are using "tty" instead of "pts" as the device type because
opening the two sides of the device are slightly different, and we are
opening the slave side here.

[BODY] Now, the UMLs are set to go, so we run a getty inside the slave UML:

[C1] UML2# /sbin/getty 38400 tty8

This will just sit there, so we now go to the slave UML, and attach
screen to its tty8:

[C1] UML1# screen /dev/tty8

[BODY] Now, you should see a login prompt in the screen session.  You should
log in and determine that it really is the other UML.  Over the course
of this chapter, we've copied different things into /tmp, assigned
different IP addresses to their network interfaces, and played with
their routing tables, so this should not be hard to verify.

[BODY] Once you log out, you'll notice that the getty exits back to the
shell, and you get no login prompt in the screen session.  This is the
purpose of the "respawn" on the getty lines in /etc/inittab.  You
could wrap the getty command in an infinite loop, and you would be
doing a passable imitation of init.  However, we will just exit the
screen session (^A K) to get back to the prompt in the other UML.



-------------------------------------------------------
This SF.Net email is sponsored by Yahoo.
Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
Search APIs Find out how you can build Yahoo! directly into your own
Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005
_______________________________________________
User-mode-linux-user mailing list
User-mode-linux-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-user

Reply via email to