Back to Home / #uml / 2007 / 09 / Prev Day | Next Day
#uml IRC Logs for 2007-09-21

---Logopened Fri Sep 21 00:00:42 2007
02:13|-|dex [] has joined #uml
03:06|-|Ancalagon [] has left #uml []
03:32|-|peterz [] has joined #uml
04:11|-|dex [] has quit [Quit: Bye bye ...]
04:26|-|tyler [] has joined #uml
04:28|-|mr_lizard_ [] has joined #uml
04:29|-|mr_lizard_ changed nick to mr_lizard
05:20|-|tyler [] has quit [Ping timeout: 480 seconds]
05:30|-|tyler [] has joined #uml
06:02|-|tyler [] has quit [Ping timeout: 480 seconds]
06:12|-|hachi [] has joined #uml
06:16<hachi>I see no allusion to the idea of using a real block device as a uml block device, is this just not possible?
06:17<hachi>or rather, I'd like to know how, if possible
06:23<hachi>ahh, it was just my mistake anyways
06:24|-|dex [] has joined #uml
06:24|-|dex [] has quit []
06:27|-|tyler [] has joined #uml
06:44<hachi>can you run a uml so that the 6 or so virtual terminals all appear as screen windows?
06:51|-|tyler [] has quit [Ping timeout: 480 seconds]
07:04|-|tyler [] has joined #uml
07:23<hachi>I can't find the boot log of my uml system, bleh
07:25<hachi>I see the uml has attached to /dev/pts/4, but I don't see any possible way for me to attach to this device and communicate with uml
07:26<hachi>so I'm stuck now with a running uml machine, and I can happily reboot it, but can't actually get to the console?
07:39|-|dang [] has quit [Quit: Leaving.]
07:59|-|dang [] has joined #uml
08:00<hachi>huh... I can't name my tuntap devices for some reason
08:16|-|mr_lizard [] has quit [Quit: Goodbye.]
08:17|-|mr_lizard [] has joined #uml
08:19|-|mr_lizard [] has quit []
08:19|-|mr_lizard [] has joined #uml
08:32<hachi>bleh, so close
08:33<hachi>if I tell it to launch a new screen session for each window, it works... can't get it to run one with them all in it
08:52<dang>That sounds very difficult...
08:52<hachi>it should be working... the xterm arg wants a program that accepts another program to run within it
08:52<hachi>screen accepts that just fine
08:53<hachi>-t sets the title... which is perfect
08:53<hachi>but I can't not supply the last argument
08:53<hachi>uml is like '3 arguments required', even if I put a comma with nothing after it
08:53<dang>Try screen -x?
08:53<hachi>-x isn't right, that implies reconnecting to a shared session
08:53<hachi>I'm already in the session
08:53<dang>I know.
08:54<hachi>screen will blow up saying "You're already in screen"
08:54<dang>The first console starts a screen, the rest attach using -x and run the appropriate screen commands to start a new window.
08:54<hachi>not the first console
08:54<dang>You can invoke screen from within screen and have it join the running screen...
08:54<dang>(at least according to my resident screen expert...)
08:54<hachi>the screen session has window 0 with the uml kernel launch in it
08:55<hachi>and that part works, uml seems to be blocking on some part of it
08:55<hachi>maybe something's crashing... hrrmmmm
08:55<hachi>it just seems like this would have been one of the first things the uml engineers would have done
08:56<dang>I just run a single console for each uml in it's own screen... The rest I connect using ssh.
08:56<dang>Well, seeing as the default is to use xterm.. :P
08:56<hachi>I mean, first reaction I had when uml launched 7 extra xterms on me was "eeeew, I want one window for this"
08:56<dang>I just need one console in case the network breaks...
08:56<hachi>well, even if you run a single console for each uml, that's still an xterm
08:56<hachi>what do people do when they run this in server farms?
08:57<hachi>you don't run an x server in those situations
08:57<dang>Nope, it's a screen.
08:57<hachi>I tried to use pty/pts mode but that's just plain broken
08:57<dang>I use stdin/out for con0
08:57<hachi>I love how it says "the pty will be announced in the boot log"
08:58<hachi>what log?
08:58<hachi>it never announces anything on any of the screens, and there's no logfile in this stuff
08:58<hachi>so you can't actually use pty mode
08:59<dang>What I do is set xterm="true,-x,-y", build my UML so con0 uses stdin/out, and run the UML in a screen.
08:59<dang>Then I can attach to that screen and get the console for that UML.
09:00|-|ram [] has joined #uml
09:00<dang>Oh, and disable all the rest of the consoles in inittab inside the uml.
09:00<dang>Works really well.
09:00<hachi>I'm sure it does, but the entry point could have been so much lower on this... now I'm reading the startup code that fires off the xterms
09:01<dang>Heh. It could be.
09:01<dang>That's why I scripted the whole thing up...
09:01<hachi>well, mine isn't working
09:01<dang>create network topologies, start multiple umls on them, the whole 9 yards.
09:01<hachi>when I fire mine up, the thing tries to launch, but something hangs/crashes
09:01<hachi>and I'm left with an incomplete startup
09:01<dang>Do you have the right build options for your UML kernel?
09:02<hachi>oh, it works fine if I let it start up a billion xterms
09:02<hachi>I just don't want that
09:02<hachi>then I tried con=pty
09:02<dang>No, that's not it.
09:02<dang>You need con=fd:0,fd:1
09:02<dang>er con0
09:02<hachi>I don't want that
09:03<dang>Why not?
09:03<hachi>cause it doesn't work for multiple consoles, hell... it doens't even give me the first tty
09:03<hachi>oh wait, it maps all 3 systems onto a single pair
09:03<dang>Just con0
09:03<dang>Then you get a single tty.
09:04<dang>You don't get multiple consoles, but you probably don't need them...
09:04<dang>Assuming you have networking set up.
09:04<hachi>but my point is
09:04<hachi>how old is uml?
09:04<hachi>didn't SOMEONE think of this yet?
09:04<hachi>everyone is engineering their way around something that's just broken
09:04<dang>I'm sure someone did...
09:05<dang>No, I'm not engineering around anything. I don't *want* multiple consoles.
09:05<dang>It's just extra resources taken up on the host box.
09:05<hachi>you certainly did engineer around it launching xterms
09:06<hachi>you had to do your own build, you said so yourself
09:06<dang>Okay, that works fine...
09:07<dang>No, I didn't have to do my own build to get around launching xterms.
09:07<dang>That's easy; just xterm="true,-x,-y"
09:07<dang>So, this seems to work.
09:07<dang>Launch the UML in a screen with a known name.
09:07<dang>Then use screen -x <name> -X screen as the console
09:07<dang>It should create a new screen window inside the old screen...
09:08<dang>At least, it does when I test it outside of UML...
09:08<hachi>what's with the -x <name>, you're already inside a screen session
09:08<hachi>that's why I use -t to set a window name
09:09<hachi>and -X screen is just redundant, just pass it the program to launch
09:09<hachi>problem is whatever I'm launching is crashing
09:09<dang>I didn't try it from inside...
09:09<hachi>screen -D -m -S lj linux umid=lj mem=384M con=xterm ubd0=/dev/miyako/lj eth0=tuntap,lj,, xterm=/home/hachi/bin/foobar,-t,-q
09:09<hachi>bleh, starting to get a bit overhead heavy... /home/hachi/bin/foobar is a debug script I have in place, normally it should just say 'screen'
09:10<dang>Let me try it...
09:13<hachi>ahh, cannot execute 'Console'
09:13<hachi>I bet the -q is getting in the way
09:13<dang>Could be...
09:14<hachi>broken quoting
09:19<hachi>yeah, it's weird... I'm running it all just fine and... what the devil is the pause() system call
09:20<dang>Stops a process until it's signaled.
09:20<hachi>so... they're using signals to do IPC... that's why it's hanging
09:21<hachi>the port-helper's that get run in my method don't have the same ppid as say, an xterm
09:21<hachi>so it just breaks
09:27<hachi>screen's setsid option seems to be helping the situation, possibly
09:27<hachi>I got some error thrown that I missed, but it's running
09:33<hachi>oh this might be funnier than I thought
09:33<hachi>screen might be launching the windows too fast for uml
09:33<hachi>and the uml port-helper thing is racing
09:33<hachi>if I slow it down just a little bit, then it all works fine
09:37<hachi>dang: got it... or at least it seems like I've solved it. I'll have to read the code to figure out why someday
09:40<hachi>I have to assume that uml doesn't make the host OS fail to s2ram or s2disk
09:46<dang>I haven't tried suspend with UML running, sorry.
09:46<dang>It *shouldn't* make a difference...
09:47|-|silug [~steve@] has quit [Read error: Connection reset by peer]
10:04|-|Intensity [] has quit [Ping timeout: 480 seconds]
10:17<hachi>it works fine
10:28|-|tasaro [] has quit [Read error: Operation timed out]
10:29|-|hfb [] has joined #uml
10:36|-|tasaro_ [] has joined #uml
10:37|-|tasaro_ changed nick to tasaro
10:42|-|tyler [] has quit [Ping timeout: 480 seconds]
10:51|-|ram [] has quit [Ping timeout: 480 seconds]
11:00|-|tyler [] has joined #uml
11:07|-|ram [] has joined #uml
11:17|-|mgross [] has joined #uml
11:44|-|tyler [] has quit [Ping timeout: 480 seconds]
11:46|-|silug [~steve@] has joined #uml
11:55|-|tyler [] has joined #uml
12:05|-|jdike [] has joined #uml
12:05<jdike>Hi guys
12:13<dang>jdike: In late today...
12:13<dang>You missed the fun screen issues.
12:25<jdike>what was that?
12:27<dang>hachi wanted to have multiple consoles opened as windows in screen, and was having trouble.
13:19|-|tyler [] has quit [Remote host closed the connection]
13:36<hachi>dang, it worked in the end, but I feel like I've stumbled on either a weird coincidence or a race condition in uml
13:37<dang>Could be...
13:37<hachi>if I make a wrapper script that sleeps for 1 second, and then launches screen with the given options, it all works perfectly
13:37<hachi>no special configs, nothing else
13:39<hachi>I can add and remove terminals on the fly, and it will add and remove them from my screen session. I need to teach the machine to shut down my uml correctly on main system shutdown, but that's all I have left :)
13:39<jdike>mconsole cad
13:39<jdike>and set the cad action in the UML's inittab to halt the thing
13:45|-|tyler [] has joined #uml
13:48|-|Blissex [] has joined #uml
14:13|-|balbir [~balbir@] has quit [Quit: Ex-Chat]
14:36|-|tyler [] has quit [Ping timeout: 480 seconds]
15:08|-|ctrace [] has joined #uml
15:10<ctrace>hiya...i have a feeling this is answered in some FAQ or something but i just haven't found it yet...
15:12<dang>We can't answer unless you ask your question...
15:18<ctrace>yup sorry :-)
15:18<ctrace>got distracted
15:18<ctrace>so i have been using UML successfully to simulate GMPLS networks by using debian 3.1 as the UML host and having each UML instance running a 2.6 kernel
15:19<ctrace>using uml_switch -unix ... -hub for the uml networking
15:20<ctrace>that all works wonderfully and we have put a lot of this work out there publically at
15:20<ctrace>but now i would like to upgrade the UML host systems to debian 4.0 and my initial testing has not been going so well
15:21<ctrace>i went through the same procedure we have used before except using debian 4.0 as the host system...installed uml-utilities, still using 2.6.20 for the UML kernel...
15:22<ctrace>the only major difference i can see is that under debian 3.1 we were using a 2.4.27 kernel and debian 4.0 is using 2.6.18
15:22<ctrace>the problem is that when I launch multiple UML instances, I can't ping between them like I can when we run everything under debian 3.1
15:24<ctrace>i am starting the UML instances with a command-line that looks something like this:
15:24<ctrace>/a/uml/debian31/linux mem=32m con1=pts umid=vlsr2 ubda=/home/dragon/uml/vlsr2,/a/uml/debian31/Debian-3.1-x86-root_fs eth0=daemon,,unix,/tmp/tmpny64rf/uml_switch_socket
15:27<dang>Should be fine... I use uml_switch on 2.6.x kernels all the time.
15:27<dang>Currently, I'm on 2.6.20, running essentially that same command line.
15:28<ctrace>hmm yeah we are using a 2.6.20 uml kernel for the instances...but the uml host is running 2.6.18
15:29<dang>I was talking about the host.
15:29<dang>I also have 2.6.20 for the instances...
15:29<ctrace>hmm interesting, maybe i will try upgrading the host kernel
15:29<ctrace>its good to know that it works for somebody else, thanks! :-)
15:30<ctrace>i don't see any errors in dmesg on the instances...
15:30<ctrace>each instance has a line like this in dmesg:
15:30<ctrace>Netdevice 0 (f2:73:ec:5a:d7:3a) : daemon backend (uml_switch version 3) - unix:/tmp/tmp9P6_j3/uml_switch_socket
15:30<dang>Oh, I specifically set the MAC addresses for the instances, tho.
15:30<dang>(because I need to do DHCP based on mac address...)
15:32<ctrace>hmm i ee
15:32<ctrace>we are actually tying all of the instances together with one UML instance that acts as a software switch
15:32<ctrace>and the MAC addresses are specifically set on that instance
15:33<ctrace>that one gets started with something like this
15:33<dang>I just use the uml_switch as a switch...
15:33<ctrace>switch1: /a/uml/debian31/linux mem=32m con1=pts umid=switch1 ubda=/home/dragon/uml/switch1,/a/uml/debian31/Debian-3.1-x86-root_fs eth4=daemon,00:00:AA:BB:00:05,unix,/tmp/tmpKSSDoL/uml_switch_socket eth3=daemon,00:00:AA:BB:00:04,unix,/tmp/tmp74wiQB/uml_switch_socket ...
15:33<dang>It uses a tun/tap to get to the host system.
15:33<dang>I have to run... Sorry I couldn't be more help.
15:33|-|dang [] has quit [Quit: Leaving.]
15:36<ctrace>np, in case anybody has a chance to look at this, we are using brctl to bridge a bunch of interfaces together on our switch instance
15:36<ctrace>so essentially the eth0's of all of the instances are connected together via this software bridge
15:38|-|Blissex [] has quit [Remote host closed the connection]
15:42<ctrace>my thinking is that it had something to do with uml_switch, because when I login to the software bridge instance (the one that has a br0 interface that ties together eth0/eth1/...) and run tcpdump, i don't see any packets making it to any of the interfaces
15:43<ctrace>whereas when I run this all under debian 3.1 with a 2.4.27 kernel on the host, it all works fine :-/
15:46<ctrace>one other data point -- if i start the UML instance using something like eth0=tuntap to give the UML instance a public IP, that all works fine under debian 4.0
15:57|-|jdike [] has quit [Quit: Leaving]
16:32|-|tyler [] has joined #uml
16:38|-|mgross [] has quit [Quit: Leaving]
16:51|-|krau [~cktakahas@] has quit [Quit: Varei!!!]
16:56<hachi>I would like to say that uml is my savior at this point. I used colinux for like 3 years now, and just got fed up with windows as the host OS... copied my images to linux and off I work
16:56<hachi>had to tweak my fstab a little bit, that's all
17:20|-|hfb [] has quit [Quit: Leaving]
17:42|-|tyler [] has quit [Remote host closed the connection]
17:48|-|ram [] has quit [Remote host closed the connection]
17:49|-|ram [] has joined #uml
17:52|-|ram [] has quit [Remote host closed the connection]
17:52|-|ram [] has joined #uml
18:01|-|dang [] has joined #uml
18:45|-|krau [] has joined #uml
19:04|-|ram [] has quit [Ping timeout: 480 seconds]
20:11|-|ram [] has joined #uml
22:43|-|krau [] has quit [Ping timeout: 480 seconds]
22:59|-|VS_ChanLog [] has left #uml [Rotating Logs]
22:59|-|VS_ChanLog [] has joined #uml
---Logclosed Sat Sep 22 00:00:51 2007