--- Day changed

--- Log opened Fri Apr 29 23:59:03 2005
00:28 -!- drbyte [~byte@intern146.lnk.telstra.net] has joined #xen
01:50 -!- Surferdude [~Surferdud@pcp08365167pcs.lndsd201.pa.comcast.net] has quit [Quit:  HydraIRC -> http://www.hydrairc.com <- IRC with a difference]
02:54 -!- drbyte [~byte@intern146.lnk.telstra.net] has quit [Quit: Leaving]
04:37 -!- DEac- [~deac@xdsl-213-196-202-197.netcologne.de] has quit [Ping timeout: 480 seconds]
04:50 -!- DEac- [~deac@xdsl-84-44-148-245.netcologne.de] has joined #xen
06:32 < knewt> aaaarrrggghhhh. basic dd use of my block device works fine, but put an ext2 on it and fill until it runs out of space and ext2 falls over with errors. so it must be going down a different, buggy, path in the second case. gah.
09:01 -!- rusty [~rusty@ppp220-136.lns1.cbr1.internode.on.net] has joined #xen
09:30 -!- rusty [~rusty@ppp220-136.lns1.cbr1.internode.on.net] has quit [Ping timeout: 480 seconds]
11:20 -!- hollis [~hollis@adsl-68-93-4-49.dsl.austtx.swbell.net] has joined #xen
11:22 -!- knewt_ [~jmb@zeus.pimb.org] has joined #xen
11:25 -!- knewt [~jmb@p213.54.69.186.tisdip.tiscali.de] has quit [Killed (NickServ command used by knewt_)]
11:25 -!- knewt_ is now known as knewt
11:53 -!- bunoc [~bun@YahooBB219206220072.bbtec.net] has joined #xen
11:54 < bunoc> hello. anybody pls tell me can i convert my domain configuration file to .sxp format ?
11:55 < bunoc> is possible, any tool to do that?
11:55 < knewt> as long as your configuration file isn't dynamic it's easy. just add the -n parameter to xm create, like it says in the help
11:59 < bunoc> knewt: then how can i ask xm to use that created file? xm create -c <created-sxp> ?
12:00 < knewt> -F instead of -f, again mentioned in the help
12:01 < knewt> (-f being optional, so you might not have been using it)
12:04 < bunoc> unfortunately xm help is so long, and scroll down my screen
12:05 < knewt> actually, it'd be "xm help create", and you just pipe it though less anyway
12:05 < knewt> (or xm create -h)
12:06 < bunoc> knewt: that helps. thank you
12:10 < riel> you can always scroll back up your screen ;)
12:11 < knewt> yay, my driver appears to be working (that bit of the functionality actually coded so far, anyway). i think on monday i can safely ask for some victims^Wfools^Wguineapigs^Wvolunteers
12:11 < bunoc> riel: rite, but i cannot scroll up too far. there is a limition
12:12 < riel> on such occasions, I ssh into the computer from another system
12:12 < riel> and scroll up inside my xterm
12:12 < riel> in fact - my test system doesn't even have a monitor or a keyboard ;)
12:12 < riel> just a serial console
12:13 < knewt> i need to get round to reactivating scrollback mode on my console server. i turned it off by mistake and it's really annoying sometimes
12:14 < knewt> thing is, i have to log into the console server physically to do so, since i deactivated everything but console connections over the network
12:14 < bunoc> riel: i am at aterm. still some limition on scrollback
12:15 < bunoc> ok get to bed now. thank you all
12:15 -!- bunoc [~bun@YahooBB219206220072.bbtec.net] has left #xen []
12:37 -!- Surferdude [~Surferdud@pcp08365167pcs.lndsd201.pa.comcast.net] has joined #xen
12:37 < Surferdude> anyone here? I need help with brctl
12:44 < riel> that's a bit vague ;)
12:44 < Surferdude> Sorry... I compiled brclt
12:45 < Surferdude> ./configure and make
12:45 < Surferdude> everything went ok... but xen's install.sh still says it isnt installed
12:46 < riel> did you install it after compiling ?
12:46 < Surferdude> yes... after compiling brctl i tried running install.sh
12:47 < Surferdude> the command brctl dosnt work, but you can access brctl via the directory
12:47 < Surferdude> and run it from there
12:48 < riel> there's your problem
12:48 < riel> the command brctl should just work
12:48 < riel> otherwise you'll get a nasty surprise when starting up xend
12:49 < Surferdude> So how do i fix it? put an alias in bash_profile?
12:49 < knewt> Surferdude: you did "make install" after the "make", right?
12:50 < Surferdude> no... guess i should
12:51 < Surferdude> [root@plain brctl]# make install
12:51 < Surferdude> mkdir -p /usr/local/sbin
12:51 < Surferdude> /usr/bin/install -c -m 755 brctl  /usr/local/sbin
12:51 < Surferdude> [root@plain brctl]#
12:51 < Surferdude> :/
12:51 < Surferdude> brb
12:51 < knewt> ok, so it's installed it into /usr/local/sbin now
12:51 < knewt> riel: fancy being one of my volunteers sometime next week?
12:51 < riel> volunteering for what ?
12:52 < knewt> testing out the driver i've been writing
12:52 < riel> what's it for?
12:52 < knewt> copy-on-write devicemapper target
12:53 < riel> nice
12:53 < riel> that sounds like fun
12:54 < knewt> it's still very early alpha status (several bits of planned functionality not coded yet for one thing), but it /appears/ to be working ok now
12:56 < knewt> i had a hateful moment at one point where i gave an invalid value to another bit of kernel code by mistake, and instead of validating it it just accepted it and then shortly afterwards crashed
13:16 < xai> eeyores birthay today!
14:04 -!- hollis [~hollis@adsl-68-93-4-49.dsl.austtx.swbell.net] has quit [Ping timeout: 480 seconds]
14:54 -!- knewt [~jmb@zeus.pimb.org] has quit [Quit: leaving]
14:56 -!- muli [~muli@alhambra.mulix.org] has quit [Ping timeout: 480 seconds]
15:18 -!- knewt [~jmb@zeus.pimb.org] has joined #xen
15:27 -!- _MarkW [~MarkWilli@hebble.cl.cam.ac.uk] has joined #xen
15:58 < _MarkW> knewt: *ping*
16:05 < knewt> _MarkW: 'lo
16:05 < _MarkW> hey, how's it goin?
16:06 < _MarkW> any luck with the CoW driver?
16:07 < knewt> good. i appear to have working basic functionality up and working :)
16:07 < _MarkW> wicked :-)
16:07 < _MarkW> booted a domain off it yet?
16:08 < knewt> nope, but shortly after i got the full code written i /did/ move from testing it directly on my laptop to inside of a domU on one of my servers. got tired of having to reboot my laptop quite so often :)
16:09 < _MarkW> heh :-) should speed things up.
16:09 < knewt> for the moment i've been testing on top of loopback devices inside the domU
16:09 < _MarkW> OK, sounds like a good plan - much faster rebooting a domU than a whole machine.
16:09 < _MarkW> (plus Kip's domain coredump code is available in the unstable tree now)
16:09 < knewt> i've been editing the source on my laptop, building an updated domU kernel, scping it to the server and booting up the domU
16:10 < knewt> haven't actually moved over to -unstable yet tbh
16:10 < Surferdude> anyone know how to switch from lilo to grub?
16:10 < _MarkW> knewt: no, probably sensible ;-)
16:11 < _MarkW> Surferdude: first step - make sure you have a means to boot your machine and fix things if you toast your MBR ;-)
16:11 < Surferdude> i have a kvm... hopefully that should be enough
16:12 < _MarkW> do you have physical access to this machine if necessary?
16:12 < Surferdude> guess lilo -u /dev/hda should do it
16:12 < knewt> my main moment of hate was when i tracked down the reason for an annoying, very repeatable oops. another bit of the kernel that i was calling into doesn't bother to validate incoming parameters, leading to the crash happening within an entirely different kernel thread from my code
16:13 < _MarkW> knewt: lots of moments of hate to be had when hacking the kernel ;-)
16:13 < Surferdude> ok... lilo is removed
16:13 < Surferdude> how do I get grub on?
16:13 < _MarkW> Surferdude: you're moving quickly ;-)
16:14 < Surferdude> =P
16:14 < _MarkW> have you installed the grub packages for your distro?
16:14 < Surferdude> yup
16:14 < Surferdude> typing grub at an ssh prompt brings up the grub menu
16:14 < _MarkW> there's a program called "grub-install" which may suffice (read the warnings in the man page) or you can do it manually from the grub prompt.
16:15 < knewt> i was passing a sector count, and had forgotten to check first that it was actually > 0. the other code just assumed that the count was at least 1, and it led to falling off the end of a linked list, trying to dereference an invalid pointer
16:15 < _MarkW> knewt: eeek!  that's rather non-obvious :-(
16:15 < Surferdude> [root@plain boot]# grub-install /dev/hda
16:15 < Surferdude> Installation finished. No error reported.
16:15 < Surferdude> This is the contents of the device map /boot/grub/device.map.
16:15 < Surferdude> Check if this is correct or not. If any of the lines is incorrect,
16:15 < Surferdude> fix it and re-run the script `grub-install'.
16:15 < Surferdude> # this device map was generated by anaconda
16:15 < Surferdude> (fd0)     /dev/fd0
16:15 < Surferdude> (hd0)     /dev/hda
16:15 < Surferdude> [root@plain boot]#
16:15 < Surferdude> I hope that works
16:16 < knewt> hehe. grub-install works great for basic stuff. of course, i've had great fun installing grub on my systems other than the laptop *g*
16:16 < _MarkW> Surferdude: looks sane.  You'll need to write a menu.lst file.
16:17 < Surferdude> looks like one was generated
16:17 < Surferdude> and all the entrys look good
16:17 < knewt> my favourite was when i installed linux on my dad's system for him in a dual-boot config. the bios on this system thinks it's helpful to change the "bios order" of drives depending on what the boot device was
16:17 < _MarkW> knewt: what are you doing for storing block remappings?  one of the problems I'm aware of with LVM is it's painful memory usage due to storing all exceptions in RAM.
16:18 < _MarkW> knewt: that's just weird!  bios writers are twisted human beings!
16:18 < _MarkW> Surferdude: if you're happy with it (and have a way to get at the machine and fix it) then it's probably time to reboot.
16:18 < Surferdude> just did
16:18 < _MarkW> it work?
16:18  * Surferdude watches the kvm
16:19  * _MarkW crosses his fingers
16:19 < Surferdude> grub menu is showing
16:19  * Surferdude presses enter and crosses his fingers
16:19 < _MarkW> woohoo! :-)
16:19 < Surferdude> Looking good...
16:20 < Surferdude> Yup... at a login prompt on the kvm
16:21 < Surferdude> Time to edit menu.lst and boot into xen (hopefully)
16:21 < _MarkW> wicked!  Xen next :-)
16:21 < _MarkW> Surferdude: you using Debian by any chance?
16:22 < Surferdude> nope... DC refused to install  it
16:22 < Surferdude> RHEL only... fighres
16:22 < Surferdude> *figurez
16:22 < Surferdude> **figures
16:24 < Surferdude> Ok... so  i need to configure my grub.conf
16:24 < _MarkW> I thought RHEL used grub by default... (I guess it's an install-time option)
16:24 < Surferdude> Dont ask... EV1 is weird
16:24 < _MarkW> Yup.  There's some guidelines in the manual.
16:25 < _MarkW> Should help you get Xen up and running, then you can start installing domains!
16:25 < Surferdude> which version of vmlinuz should i use?
16:26 < _MarkW> You need to use the vmlinuz-foo-xen0
16:27 < _MarkW> you can run any domain using a xen0 kernel.  xenU is the same but without drivers for real hardware (hence smaller) - it can only run in unpriv domains.
16:27 < Surferdude> kernel /vmlinuz-2.6-xen0
16:28 < Surferdude> now for root
16:28 < _MarkW> hang on...
16:28 < _MarkW> kernel xen.gz
16:28 < Surferdude> k
16:28 < _MarkW> sorry: kernel /xen.gz
16:28 < _MarkW> module /vmlinuz-2.6.whatever-xen0
16:28 < _MarkW> k?
16:29 < Surferdude> ok
16:29 < Surferdude> and what do i do for root
16:29 < _MarkW> set it the same as for your other grub entries.
16:29 < Surferdude> Ok
16:29 < _MarkW> make sure the path to xen.gz and vmlinuz is the same as the path for the other grub entries
16:30 < _MarkW> what flavour of RHEL is this?  you use udev?
16:30 < Surferdude> i think its version three (taroon)
16:31 < Surferdude> title XenLinux 2.0.5
16:31 < Surferdude>         root (hd0,0)
16:31 < Surferdude>         kernel /xen.gz
16:31 < Surferdude>         module /vmlinux-2.6-xen0
16:31 < Surferdude> good?
16:31 < knewt> _MarkW: quick calculation says that with the default chunk size, a 2GB cow mapping will take up about 164Kb, increasing as required during high concurrency cow-ing
16:32 < knewt> i think i've got the calculations correct
16:32 < _MarkW> Surferdude: yes but you need to add some arguments to the xen and vmlinux lines
16:32 < Surferdude> like the ro and root=/dev/sda
16:32 < _MarkW> have a look at the user manual for some examples
16:32 < _MarkW> yup.
16:32 < _MarkW> knewt: OK, that sounds not too bad :-)
16:32 < _MarkW> what does the on-disk layout look like?
16:33 < Surferdude> title XenLinux 2.0.5
16:34 < Surferdude>         root (hd0,0)
16:34 < Surferdude>         kernel /xen.gz ro root=/dev/sda
16:34 < Surferdude>         module /vmlinux-2.6-xen0
16:35 < knewt> i'm going to create a mode with a small header to the bitmap, but the basic version i've started with is a pure bitmap, nothing else. you can use completely seperate bitmap and cow devices if you want (and i have been during testing)
16:36 < _MarkW> Surferdude: nope.  ro and root are arguments that Linux is interested in
16:36 < _MarkW> so they go on the Linux line.  there are different arguments for Xen itself.
16:36 < Surferdude> Yeah, i was just looking at the manual
16:37 < knewt> _MarkW: i've also managed to keep concurrency within the in-memory structures about as high as i think is possible :)
16:37 < Surferdude> title XenLinux 2.0.5
16:37 < Surferdude>         root (hd0,0)
16:37 < Surferdude>         kernel /xen.gz dom0_mem=131072
16:37 < Surferdude>         module /vmlinux-2.6-xen0 root=/dev/sda ro
16:37 < Surferdude> I think i got it this time
16:37 < _MarkW> knewt: that's good to hear
16:38 < _MarkW> Surferdude: I thought your root was on hda?
16:38 < knewt> i'll try and come up with a nice ascii-diagrammed text file describing the algorithm if you're interested?
16:38 < Surferdude> I think so...
16:39 < Surferdude> and all the other entrys are root=LABEL=/
16:40 < Surferdude> maybe i should try that?
16:40 < _MarkW> knewt: only if you have time :-)
16:40 < _MarkW> the main problems with previous solutions were memory usage and the on-disk layout
16:41 < _MarkW> and performance of course ;-)
16:43 < knewt> once a particular chunk has been cow'ed it's virtually no overhead above a simple linear mapping for writing (a single bit-test). and reading is always just basicaly a single bit-test over a linear
16:43 < _MarkW> a couple of other things that we noted as important when Bin looked into this: how much disk space do you think the metadata will require?  how much work might resizing support require?
16:45 < knewt> assuming you just want to resize the cow'ed device (and i can't see resizing the backing device making sense), i'd suggest just appending a linear mapping after the cow mapping and then resizing the filesystem
16:46 < _MarkW> Ian had a plan to thread remapping metadata in between CoW'd blocks (!) on the writeable device.  That way, some seeks are (hopefully) avoided and the resizing of the writeable volume should Just Work.
16:46 < _MarkW> Do you have problems with the size of your bitmap if resizing is done?
16:47 < Surferdude> getting a file not found on the vmlinuz when bootinf
16:47 < Surferdude> booting
16:48 < knewt> that 2GB example from earlier, with the default chunk size, takes 64Kb of bitmap space on disk. when header code is in i would imagine only 512bytes or 1Kb for the header.
16:48 -!- muli [~muli@alhambra.mulix.org] has joined #xen
16:48 < _MarkW> Surferdude: double check your grub options for typos (maybe vmlinux vs vmlinuz?)
16:49 < Surferdude> your right... heh
16:49 < Surferdude> I knew this kvm would come in handy
16:50  * knewt finds a terminal server very handy
16:50  * _MarkW uses running down the corridor with a hammer instead of a kvm
16:51 < Surferdude> I tried installing Xen on this machine, but it wouldent boot no matter what i tried
16:51 < riel> a hammer?  you have to hit that reset button really hard, huh? ;)
16:51 < _MarkW> The server room seems conveniently close until you have to start going there every 2 minutes.
16:51 < riel> nothing like serial console + remote power switch
16:52 < _MarkW> riel: If your machines don't respect you, you got nothin' ;-)
16:52 < knewt> i keep meaning to build my own remote power switch :)
16:52 < Surferdude> lol
16:52 < _MarkW> Surferdude: you must be close to Xenification now though...
16:52 < Surferdude> Yup
16:54 < _MarkW> whoa!  just spent an hour on this filesystem code without noticing!
16:54 < _MarkW> time for a typing break, i'll be back in a bit.
16:56 < Surferdude> well... it boots the profile, but still getting the nfs error
16:56 < Surferdude> "unable to mount root fs via nfs"
16:57 < Surferdude> anyone?
16:59 < knewt> what have you used as root= ?
16:59 < Surferdude> root=LABEL=/
16:59 < knewt> that won't work without an initrd
16:59 < Surferdude> ah
16:59 < knewt> just use the actual device name. much easier imho
17:00 < yosh> is initrd known broken with xen 2.0.5?
17:02 < knewt> not that i'm aware. i'm using an initrd a -testing not that much further along than 2.0.5 iirc
17:02 < knewt> s/initrd a/initrd with a/
17:02 < yosh> hm, I was running into trouble
17:03 < knewt> i need it to boot off an evms device :)
17:03 < yosh> Initial guest OS requires too much space
17:03 < yosh> (3500MB is greater than 512MB limit)
17:03 < yosh> ERROR: Error constructing guest OS
17:04 < Surferdude> trying /dev/sda
17:05 < knewt> err. didn't grub-install say it was /dev/hda ?
17:06 < yosh> the initrd is only 4 MB, so I'm not sure where it's getting the 3500MB from
17:12 -!- DEac- [~deac@xdsl-84-44-148-245.netcologne.de] has quit [Ping timeout: 480 seconds]
17:14 < Surferdude> dev/hda isnt working either :(
17:14 < Surferdude> Unable to mount root fs on unknown block
17:15 < Surferdude> help?
17:17 < _MarkW> Surferdude: you need to create some device nodes or a Xen initrd
17:17 < Surferdude> just define another module?
17:17 < _MarkW> yosh: what version of Xen are you running? I remember a bug with initrds a while ago
17:17 < Surferdude> in grub.conf?
17:18 < _MarkW> Surferdude: yes, but you should strictly run mkinitrd to make a Xenified initrd (your exsiting RHEL initrd might work, tho)
17:18 < yosh> _MarkW: 2.0.5
17:19 < _MarkW> yosh: weird.  it should work.  can you have a quick search of the mail archives for the "requires too much space" or similar errors?
17:20 < _MarkW> i think the problem was resolved there (it might even be fixed in -testing, I guess)
17:20 < Surferdude> run intrd from a shell prompt?
17:20 < Surferdude> mkintrd?
17:21 < yosh> _MarkW: I didn't find anything
17:21 < _MarkW> yosh: definitely there somewhere.  it could be in either xen-users or xen-devel, or on the sf.net xen-devel list
17:22 < _MarkW> Surferdude: mkinitrd auto-builds an initrd.
17:22 < _MarkW> try the RHEL initrd first tho - might work.
17:26 -!- DEac- [~deac@xdsl-195-14-219-194.netcologne.de] has joined #xen
17:26 < yosh> _MarkW: ah, it's on sf.net (bleh, I hate the list interface there)
17:27 < _MarkW> yosh: so do I.  GMane, I believe, has a unified archive for both the old and new xen-devel lists.
17:28 < _MarkW> yosh: does it give any clues about your problem?
17:28 < Surferdude> This is getting really really annoying
17:28 < yosh> _MarkW: still looking...
17:31 < _MarkW> Surferdude: try mkinitrd /boot/initrd-2.6.11-xen0.img 2.6.11-xen0
17:35 < Surferdude> at a shell prompt
17:35 < Surferdude> ?
17:36 < _MarkW> Surferdude:  yup.  that'll build you a Xenified RHEL initrd (you might have to tweak the naming depending on the version you've installed)
17:36 < _MarkW> you can then stick that in another module line and it might even work!
17:45 < knewt> _MarkW: ok, i've got some completely unscientific speed test results :)    writing out 1gig to a linear mapping took 28seconds.  the same with a brand new cow mapping took 35seconds.  then filled up the cow mapping filesystem to the max, removed the dummy file, and wrote out the 1gig again. 28.7seconds
17:47 < _MarkW> knewt: sounds promising!
17:51 < knewt> i could probably get it faster by providing an option to not write out the bitmap more frequently then every N jiffies, but i'm not sure if i'd want to create an unsafe option like that
17:51 -!- jonmason [~jonmason@pixpat.austin.ibm.com] has quit [Read error: Connection reset by peer]
17:53 < knewt> once i've got everything i've already planned up and working, i might look at creating an interwoven bitmap/cow mode
17:54 < knewt> see how much if any speed improvement that might give
17:55 < _MarkW> cool.  a decent cow implementation would be very useful to a lot of people
17:58 -!- jonmason [~jonmason@pixpat.austin.ibm.com] has joined #xen
17:59 < knewt> want to be a guineapig^Wvolunteer sometime next week?
18:02 < _MarkW> knewt: i'm interested to see what you come up with but can't guarantee when i'll get a chance to try it out
18:04 < _MarkW> if you send me a link, i can have a poke at some point
18:04 < _MarkW> alternatively, if you post to xen-devel I imagine you will get plenty of feedback ;-)
18:05 < knewt> heh. yeah. i want to do some clean-up at minimum before i give it out for testing, which is why sometime next week
18:05 < knewt> i might even get the background cow-ifying mode in there in that time
18:06 < _MarkW> background cowifying?
18:07 < _MarkW> sounds cool whatever it is...
18:07 -!- nextime [~nextime@213-140-6-96.fastres.net] has quit [Quit: BitchX-1.0c19 -- just do it.]
18:09 < knewt> the standard mode is "ondemand", which only copies across from the backing device to the cow device when a write is carried out. "background" mode additionally makes copies of chunks spontaneously from a very low priority thread running in the background
18:10 -!- edsuom [~edsuom@207-118-65-127.dyn.centurytel.net] has quit [Quit: Real work beckons]
18:13 < knewt> so you could, for instance, create a new cow mapping for a domain, and use background mode. even if no writes are made to the mapping, eventually the entire contents will be cow-ified across and will increase the event count of the device. so you could have a user task waiting on that event, and when it triggers load a new linear mapping into the inactive table slot and then switch over to it
18:16 < knewt> did that get through?
18:17 < _MarkW> yup
18:18 < _MarkW> i was distracted
18:18 < _MarkW> makes sense.
18:18 < _MarkW> basically a fork() for disks that eventually makes them independent - cool.
18:18 < knewt> cool. my tunnel was down for a couple of minutes due to the annoying 24h bounce. i've never sent text through during that time before
18:19 < _MarkW> 24h bounce?
18:19 < knewt> over here the isp's are gits and even on adsl they like, all, bounce you every 24 hours
18:20 < _MarkW> Ah, that's pretty nasty!
18:20 < knewt> you can't even get a single static IP without paying for a business line
18:20 < knewt> i used to have a /29 on a residential when i was still in the UK
18:24 < _MarkW> my connectivity is via the university, so it's fairly decent
18:26 < knewt> unfortunately i run out of money in about a month or two for the virtual server i pay for, at which point i'll lose the tunnel :(
18:27 < _MarkW> :-(
18:32 -!- aliguori [~anthony@cpe-70-112-81-91.austin.res.rr.com] has joined #xen
18:32 -!- aliguori [~anthony@cpe-70-112-81-91.austin.res.rr.com] has quit [Remote host closed the connection]
18:36 < riel> knewt: get a free ipv6 tunnel for your irc connections ;)
18:38 < _MarkW> Surferdude: did you have any luck with mkinitrd?
18:40 < knewt> XenSource don't have any jobs going do they? *g*
18:41 < riel> you might want to ask
18:44 -!- aliguori [~anthony@cpe-70-112-81-91.austin.res.rr.com] has joined #xen
18:44 -!- aliguori [~anthony@cpe-70-112-81-91.austin.res.rr.com] has quit [Quit: ]
18:44 < _MarkW> knewt: no idea but it might actually be worth asking.  they don't seem to advertise as such for tech positions, so if you don't ask, you won't get.
18:45 -!- Arnald [~Arnald@81-86-116-102.dsl.pipex.com] has quit [Ping timeout: 480 seconds]
18:47 -!- aliguori [~anthony@cpe-70-112-81-91.austin.res.rr.com] has joined #xen
18:47 -!- aliguori [~anthony@cpe-70-112-81-91.austin.res.rr.com] has quit [Remote host closed the connection]
19:02 -!- hollis [~hollis@user-0vvde2g.cable.mindspring.com] has joined #xen
19:36 < Surferdude> back to work...
19:39 < _MarkW> Surferdude: heh :-)  let me know how you get on
19:39 < Surferdude> what was that command again?
19:40 < _MarkW> mkinitrd /boot/initrd-2.6.11-xen0.img 2.6.11-xen0
19:40 < _MarkW> or something like that
19:43 < Surferdude> lib/modules/2.6.11-xen0 is not a directory
19:47 -!- wenchien [~wenchien@221-169-69-23.adsl.static.seed.net.tw] has quit [Ping timeout: 480 seconds]
19:47 < _MarkW> Surferdude: what is your vmlinuz called?
19:47 < Surferdude> hold on... booting
19:47 < Surferdude> getting a serial input error
19:47 < Surferdude> on booting xen
19:47 < _MarkW> the version number to mkinitrd should be the same as that version
19:47 < Surferdude> diddnt let me do mkinitrd
19:48 < _MarkW> it should work.
19:49 < Surferdude> is there any way to access grub.conf from grub itself
19:49 < hollis> doesn't GRUB have a "cat" command?
19:49 < Surferdude> no clue
19:49 < hollis> well, are you in GRUB now?
19:50 < knewt> yes, it has a cat command
19:51 < Surferdude> title XenLinux 2.0.5
19:51 < Surferdude>         root (hd0,0)
19:51 < Surferdude>         kernel /xen.gz dom0_mem=131072
19:51 < Surferdude>         module /vmlinuz-2.4-xen0 root=/dev/hda ro
19:51 < Surferdude>         initrd /intrd-2.4.21-27.el.img
19:52 < Surferdude> Whenever i boot that configuration, i get a serial input error
19:54 < _MarkW> Surferdude: don't use an "initrd" line, use a second module line.
19:54 < _MarkW> the grub initrd line will break things - don't ask me why :-)
19:54 -!- soffi_ [~soffi@Tolvudeild-SC-gw.vv.simnet.is] has quit [Ping timeout: 480 seconds]
19:55 -!- soffi_ [~soffi@Tolvudeild-SC-gw.vv.simnet.is] has joined #xen
19:57 -!- JViz [Anomaly@cpe-065-190-045-054.triad.res.rr.com] has quit [Ping timeout: 480 seconds]
20:09 < Surferdude> still getting this stupid serial input error... argh!
20:11 < Surferdude> has anyone experienced this?
20:16 < _MarkW> Surferdude: nope, never heard of it before
20:20 < Surferdude> Ok... changed the kernel back to the way it was and now getting the "cannot mount root fs" message
20:20 < Surferdude> mkinitrd isnt working
20:22 < knewt> i notice it's a 2.4 kernel. is the filesystem designed for devfs and you don't have devfs compiled into the dom0 kernel?
20:23 < Surferdude> how would i find that out
20:24 < _MarkW> yes, i was worried about the 2.4-ness as well
20:24 < _MarkW> Surferdude: what release of RHEL is this?
20:25 < _MarkW> Surferdude: to find out if you're using devfs, type "mount" under an standard boot of RHEL and see if devfs is listed
20:25 < Surferdude> ok
20:25 < Surferdude> rebooting now
20:25 < Surferdude> was trying to see if xenU was working
20:25 -!- JViz [Anomaly@cpe-065-190-046-093.triad.res.rr.com] has joined #xen
20:26 -!- hollis [~hollis@user-0vvde2g.cable.mindspring.com] has quit [Quit: leaving]
20:27 < Surferdude> [root@plain root]# mount
20:27 < Surferdude> /dev/hda3 on / type ext3 (rw)
20:27 < Surferdude> none on /proc type proc (rw)
20:27 < Surferdude> none on /dev/pts type devpts (rw,gid=5,mode=620)
20:27 < Surferdude> /dev/hda1 on /boot type ext3 (rw)
20:27 < Surferdude> none on /dev/shm type tmpfs (rw)
20:27 < Surferdude> [root@plain root]#
20:28 < knewt> ok. so you should be using root=/dev/hda3
20:30 < _MarkW> Surferdude: this is all very interesting because your problem clearly isn't what I expected :-)
20:30 < _MarkW> where did you get your XenLinux kernel from?
20:30 < Surferdude> i got the prebuilt tarball from xen.sourceforge.net
20:31 < _MarkW> ok, use the 2.4-xen0 kernel for now.  just set your root=/dev/hda3 in the grub config like knewt said.
20:32 < Surferdude> Ok
20:32 < Surferdude> title XenLinux 2.0.5
20:32 < Surferdude>         root(hd0,0)
20:32 < Surferdude>         kernel /xen.gz dom0_mem=131072
20:32 < Surferdude>         module /vmlinuz-2.4-xen0 root=/dev/hda3 ro
20:33 < Surferdude> I hope that works
20:33 < _MarkW> Surferdude: looks good.
20:34 < Surferdude> back to the serial input error
20:35 < Surferdude> I think that has somthing to do with the kvm
20:36 < _MarkW> do you actually have a serial line attached?
20:36 < knewt> how far is it getting? is it erroring in grub? in xen? in linux?
20:36 < Surferdude> yes its a serial kvm
20:36 < Surferdude> its erroring a few seconds after i select it in grub
20:36 < _MarkW> in Xen itself?
20:37 < Surferdude> I am assuming so
20:37 < _MarkW> what does the error say?
20:37 < Surferdude> Somthing like "serial input error: press ctrl+a three times to enable serial access
20:37 < Surferdude> tried doing that
20:37 < Surferdude> just reboots
20:40 < Surferdude> This is really stumping me :/
20:42 < knewt> what processor do you have?
20:42 < Surferdude> Intel Celeron
20:43 < _MarkW> the ctrl+a thing is normally printed out when Xen starts
20:43 -!- tierra [~tierra@c-24-10-173-249.hsd1.ut.comcast.net] has joined #xen
20:43 < Surferdude> yeah but it just reboots right after it shows
20:43 < _MarkW> are you sure it's a serial error and not just the serial message interleaved with the real error?
20:44 < Surferdude> I cant tell...
20:44 < knewt> the normal message about ctrl-a is: "*** Serial input -> DOM0 (type 'CTRL-a' three times to switch input to Xen)."
20:44 < Surferdude> thats
20:44 < Surferdude> thats it
20:44 < _MarkW> Surferdude: Yup that's normal.
20:44 < _MarkW> So it's not the serial line that's the problem.
20:44 < knewt> Surferdude: the lines immediately above that, do they mention loading domain 0?
20:45 < _MarkW> Some bit of configuration must be out of place.
20:45 < Surferdude> So what is O_o
20:45 < _MarkW> If you put "noreboot" onto the Xen grub command line then it won't reboot automatically (you'll have to power cycle the box)
20:45 < _MarkW> That way you can have a better look at the error.
20:47 < Surferdude> thats when it boots right?
20:47 < Surferdude> when i am @ the grub menu
20:47 < _MarkW> you can press "e" on the Xen menu entry, then "e" to edit the "kernel xen.gz" line, then add it on.
20:47 < knewt> yeah. needs to go on the "kernel" line
20:48 < _MarkW> then press return, then b to boot.
20:51 < Surferdude> Ok... just freezes at the serial input message
20:51 < _MarkW> OK, that's weird.  No visible error messages?
20:52 < demon> the linux kernel needs to be told where to direct its console output, it'll want to output it to the local console, not serial...
20:52 < _MarkW> demon: good point! :-)
20:52 < demon> try appending 'console=ttyS0,[speed]' to the kernel command line
20:52 < demon> also, do you have a line in inittab to spawn a getty on the serial port?
20:52 < demon> MarkW: I've installed xen by wire on a few boxes :)
20:53 < Surferdude> no other errors... adding the kernel arg now
20:53 < demon> er, make sure you append that to the linux kernel's command line
20:53 < _MarkW> Surferdude: stick "console=ttyS0" to the end of the vmlinuz line
20:53 < demon> not the xen kernel's
20:53 < _MarkW> works on my test box here
20:54 < _MarkW> you needn't worry about the speed for that line, since Linux doesn't get to control it anyhow.
20:54 -!- rusty [~rusty@ppp220-136.lns1.cbr1.internode.on.net] has joined #xen
20:55 < Surferdude> same error...
20:55 < demon> no further output?
20:55 < demon> did you build the XenoLinux kernel yourself, or is it some kind of packaged kernel?
20:55 < _MarkW> Surferdude: can you show us what your menu.lst entry currently looks linke?
20:56 < Surferdude> Sure... give me a sec
20:57 -!- hollis [~hollis@user-0vvde2g.cable.mindspring.com] has joined #xen
20:58 -!- tierra [~tierra@c-24-10-173-249.hsd1.ut.comcast.net] has quit [Remote host closed the connection]
20:58 < knewt> heh. looking over my menu.lst file reminds me of when i upgraded my dom0 and suddenly found that the initrd support had been fixed, and that my workaround to deal with the prior bug didn't work any more :/
20:58 < Surferdude> What the hell... i cant even access ssh anymore
21:00 < Surferdude> Crap... might as well get another 24 hours on the kvm
21:01  * riel hurts his head on more VM stuff
21:02 < Surferdude> there isnt anything on menu.lst about xen
21:02 < Surferdude> wait... nevermind
21:02 < Surferdude> there is
21:03 < _MarkW> riel: what you up to in the VM?  the VFS is hurting my head right now...
21:03 < Surferdude> heres the entry in menu.lst
21:03 < Surferdude> title XenLinux 2.0.5
21:03 < Surferdude>         root(hd0,0)
21:03 < Surferdude>         kernel /xen.gz dom0_mem=131072
21:03 < Surferdude>         module /vmlinuz-2.4-xen0 root=/dev/hda3 ro
21:04 < _MarkW> can you please stick "console=tty0 console=ttyS0" onto the end of that module line?
21:05 < Surferdude> in menu.lst?
21:05 < _MarkW> yeah, it'll need to be there so might as well add it permanently.
21:05 < demon> Surferdude: did you build the XenoLinux kernel yourself, or is this some kind of packaged kernel you're using?
21:06 < Surferdude> its prebuilt
21:06 < Surferdude> title XenLinux 2.0.5
21:06 < Surferdude>         root(hd0,0)
21:06 < Surferdude>         kernel /xen.gz dom0_mem=131072
21:06 < Surferdude>         module /vmlinuz-2.4-xen0 root=/dev/hda3 ro console=tty0
21:06 < Surferdude> console-ttyS0
21:06 < demon> okay... are you sure it supports your IDE controller and NIC?
21:06 < demon> that should be console=ttyS0
21:06 < demon> not console-ttyS0
21:07 < demon> is there an initrd that came with that kernel, perhaps?
21:07 < _MarkW> demon: if we can at least get some output on the serial line then we can figure out what it doesn't like.
21:07 < _MarkW> i don't think it's using udev or anything like that so it shouldn't need an initrd.
21:07 < Surferdude> ok...  rebootinng
21:08 < _MarkW> It's probably lacking the IDE controller driver, I guess.
21:09 < riel> _MarkW: http://wiki.linux-mm.org/wiki/AdvancedPageReplacement
21:09 < Surferdude> its...working!!!!
21:09 < riel> _MarkW: I'm designing a Clock-Pro variation that can be implemented in the Linux VM
21:09 < _MarkW> Surferdude: wicked!
21:10 < _MarkW> we can all give ourselves a pat on the back :-)
21:10 < demon> Surferdude: okay, now is it giving you any kind of error?
21:10 < _MarkW> riel: arrrghhh you scary man :-)
21:10 < Surferdude> Well... it gave me the warning aboout lib/tls
21:10 < Surferdude> but the terminal still shows RHEL
21:10 < riel> _MarkW: want me to forward you the patch I sent out friday ? ;)
21:10 < demon> ok... that would seem to mean it's mounting the filsystem and spawning init
21:10 < Surferdude> at the login prompt
21:10 < _MarkW> Surferdude: OK, that's standard, just move /lib/tls out of the way so it won't get used.
21:11 < riel> if you run Fedora, you want to keep /lib/tls
21:11 < _MarkW> riel: I'd quite like to see the patch actually actually
21:11 < Surferdude> I know that, but should i worry about it still saying RHEL?
21:11 < riel> otherwise RPM database locking doesn't go right
21:11 -!- nextime [~nextime@213-140-6-96.fastres.net] has joined #xen
21:11 < Surferdude> at the login prompt
21:11 < Surferdude> ?
21:11 < demon> well, you're still running RHEL
21:11 < riel> Surferdude: don't worry about it saying RHEL
21:11 < demon> so yeah, that's normal
21:11 < riel> _MarkW: what's your email address again ?
21:11 < _MarkW> Surferdude: log in and play!
21:11 < Surferdude> ok... good
21:11 < Surferdude> datruesurfer@gmail.com
21:11 < _MarkW> riel: mark.williamson@cl.cam.ac.uk
21:12 < Surferdude> wow... i am so excited that i forgot my root password for a second
21:12 < _MarkW> Surferdude: you should be able to bring up some domains now :-)  try the ttylinux example in the user manual for starters - it's nice and simple.
21:13 < Surferdude> xend start brings up a whole lot of errors
21:13 < Surferdude> :/
21:13 < _MarkW> have you installed twisted?
21:13 < Surferdude> yes
21:13 < Surferdude> all python errors
21:13 < riel> Surferdude: make sure to leave /lib/tls in place, if you value /var/lib/rpm/ ;)
21:14 < knewt> eh. i didn't think the 2.4 kernel supported /lib/tls anyway?
21:14 < _MarkW> Surferdude: OK, lets see the Python spew.  It's probably something straightforward.
21:14 < riel> knewt: RHEL3 does
21:14 < knewt> aah
21:14 < _MarkW> knewt: they don't but this is a RedHatMegaPatch 2.4 :-)
21:15 < demon> probably just version warnings
21:15 < riel> _MarkW: the reason of that patch (in RHL8 & 9) was to prepare userland for 2.6
21:15 < Surferdude> import error: no module named logging
21:15 < _MarkW> except - it's running a Xen 2.4 kernel now, so I'm not sure why it would be using TLS...
21:15 < Surferdude> thats what it ends with
21:15 < riel> _MarkW: it worked well enough, and there was enough customer demand, that it got included in RHEL3
21:15 < _MarkW> Surferdude: ah, you'll be missing the python logging framework then
21:15 < riel> _MarkW: good point
21:15 < _MarkW> spooky...
21:15 < Surferdude> how do i get that working?
21:16  * _MarkW scratches his head
21:16 < _MarkW> what python version are you running?
21:18 < Surferdude> Wont even let me see that :/
21:18 < _MarkW> ?
21:18 < _MarkW> python --version
21:18 < _MarkW> oops, no, that's not it...
21:19 < _MarkW> python -V should tell you
21:19 < Surferdude> 2.2.3
21:20 < _MarkW> Surferdude: you'll probably need to install the logging package as an add-on
21:20 < _MarkW> it wasn't standard until 2.3
21:20 < knewt> ok, i think it's time for me to grab some shuteye,  a) it being gone 3am, and b) /me having got a good idea of how i'm going to code interleaving why i come to implement it
21:21 < Surferdude> Where/how do i do that?
21:21 < _MarkW> knewt: see ya.
21:21 < _MarkW> Surferdude: i'm working on it...
21:21  * knewt & # ...off to see the wizard...
21:22 < _MarkW> Surferdude: wget http://www.red-dove.com/logging-0.4.9.5.tar.gz
21:22 < _MarkW> tar xzf logging-0.4.9.5.tar.gz
21:22 < _MarkW> cd logging-0.4.9.5
21:22 < _MarkW> python setup.py install
21:24 < Surferdude> host not found
21:24 < _MarkW> ifconfig
21:24 < _MarkW> see if eth0 appears
21:24 < Surferdude> nope
21:25 < Surferdude> ifconfig eth0?
21:25 < _MarkW> you're missing the driver for your network card
21:25 < _MarkW> you'll need to build a new kernel with support for your network
21:25 < _MarkW> if you don't want to do that just yet then you could just reboot into vanilla linux to do the download
21:28 < _MarkW> riel: is anybody actively working on the compressed caching project?
21:28 < _MarkW> i always thought it looked quite cool but couldn't see any obvious signs of life on the website.
21:29 < Surferdude> Looks like I have to go on a download hunt
21:30 < riel> _MarkW: not lately afaik
21:30 < riel> _MarkW: and yes, compressed caching looks very promising
21:31 < _MarkW> does any OS use it presently?
21:31 < riel> not afaik
21:32 < _MarkW> *yawn*
21:32 < _MarkW> Time for me to go to bed!
21:32 < _MarkW> Surferdude: good luck with setting things up.  I'll probably be back around the same time tomorrow.
21:33 < Surferdude> Later... thanks for your help
21:33 < _MarkW> riel: thanks for the links / code - I'll check it out when I'm more awake ;-)
21:33  * _MarkW goes
21:33 -!- _MarkW [~MarkWilli@hebble.cl.cam.ac.uk] has quit [Quit: Connection interrupted by tinfoil hat]
22:47 -!- grifferz [andy@laudanum.strugglers.net] has joined #xen
--- Log closed Sat Apr 30 23:59:00 2005