Back to Home / #uml / 2007 / 10 / Prev Day | Next Day
#uml IRC Logs for 2007-10-24

---Logopened Wed Oct 24 00:00:54 2007
00:08|-|arun [~arun@ool-44c6b6b1.dyn.optonline.net] has joined #uml
00:08|-|dsoul_ [darksoul@vice.ii.uj.edu.pl] has joined #uml
00:11|-|Magotari_ [~karol@chello089076064182.chello.pl] has joined #uml
00:12|-|Magotari [~karol@chello089076064182.chello.pl] has quit [Read error: Connection reset by peer]
00:12|-|jdike [~jdike@pool-71-248-190-161.bstnma.fios.verizon.net] has quit [Quit: Leaving]
00:12|-|Netsplit cation.oftc.net <-> kilo.oftc.net quits: dsoul, SNy, Urgleflogue
00:13|-|Netsplit over, joins: dsoul, Urgleflogue, SNy
00:14|-|dsoul [darksoul@vice.ii.uj.edu.pl] has quit [Ping timeout: 480 seconds]
01:15|-|Baltam32 [~WIKIMOKI@tor-irc.dnsbl.oftc.net] has joined #uml
01:19|-|Netsplit synthon.oftc.net <-> charon.oftc.net quits: Hunger, weasel, apic, dgraves
01:20|-|Netsplit over, joins: weasel, Hunger, dgraves, apic
01:21|-|Baltam8 [~WIKIMOKI@tor-irc.dnsbl.oftc.net] has quit [Ping timeout: 480 seconds]
01:22|-|Electric1lf [~dbharris@76.64.54.113] has quit [Ping timeout: 480 seconds]
01:34|-|arun [~arun@ool-44c6b6b1.dyn.optonline.net] has joined #uml
01:41|-|ElectricElf [~dbharris@76.64.54.113] has joined #uml
01:56|-|aroscha [~aroscha@chello213047053193.30.11.tuwien.teleweb.at] has joined #uml
02:14|-|aroscha [~aroscha@chello213047053193.30.11.tuwien.teleweb.at] has quit [Quit: aroscha]
02:21|-|aroscha [~aroscha@chello213047053193.30.11.tuwien.teleweb.at] has joined #uml
02:25|-|aroscha [~aroscha@chello213047053193.30.11.tuwien.teleweb.at] has quit []
04:58|-|darious12 [~darius@athedsl-302112.home.otenet.gr] has joined #uml
05:25|-|aroscha [~aroscha@chello213047053193.30.11.tuwien.teleweb.at] has joined #uml
05:37|-|tyler29 [~tyler@ARennes-257-1-135-146.w86-210.abo.wanadoo.fr] has joined #uml
06:15|-|tyler29 [~tyler@ARennes-257-1-135-146.w86-210.abo.wanadoo.fr] has quit [Ping timeout: 480 seconds]
06:22|-|darious12 [~darius@athedsl-302112.home.otenet.gr] has quit [Remote host closed the connection]
06:37|-|tyler29 [~tyler@ARennes-257-1-110-241.w86-210.abo.wanadoo.fr] has joined #uml
06:39|-|aroscha_ [~aroscha@chello213047053193.30.11.tuwien.teleweb.at] has joined #uml
06:45|-|aroscha [~aroscha@chello213047053193.30.11.tuwien.teleweb.at] has quit [Ping timeout: 480 seconds]
06:53|-|aroscha_ [~aroscha@chello213047053193.30.11.tuwien.teleweb.at] has quit [Quit: aroscha_]
06:54|-|aroscha [~aroscha@chello213047053193.30.11.tuwien.teleweb.at] has joined #uml
06:56|-|aroscha_ [~aroscha@chello213047053193.30.11.tuwien.teleweb.at] has joined #uml
06:56|-|aroscha [~aroscha@chello213047053193.30.11.tuwien.teleweb.at] has quit [Read error: Connection reset by peer]
06:57|-|aroscha_ [~aroscha@chello213047053193.30.11.tuwien.teleweb.at] has quit []
07:42|-|tyler29 [~tyler@ARennes-257-1-110-241.w86-210.abo.wanadoo.fr] has quit [Ping timeout: 480 seconds]
07:54|-|tyler29 [~tyler@ARennes-257-1-140-124.w86-210.abo.wanadoo.fr] has joined #uml
08:05|-|tyler29 [~tyler@ARennes-257-1-140-124.w86-210.abo.wanadoo.fr] has quit [Ping timeout: 480 seconds]
08:10|-|krau [~cktakahas@200.184.118.132] has quit [Quit: Varei!!!]
08:21|-|krau [~cktakahas@200.184.118.132] has joined #uml
08:24|-|tyler29 [~tyler@ARennes-257-1-73-102.w81-53.abo.wanadoo.fr] has joined #uml
08:41|-|DomQ [~DomQ@streamcore.pck.nerim.net] has joined #uml
08:48|-|dang [~dang@nemesis.fprintf.net] has quit [Quit: Leaving.]
09:09|-|dang [~dang@aa-redwall.nexthop.com] has joined #uml
09:36|-|dan1 [~dang@aa-redwall.nexthop.com] has joined #uml
09:37|-|dang [~dang@aa-redwall.nexthop.com] has quit [Ping timeout: 480 seconds]
09:50|-|jdike [~jdike@pool-71-248-190-161.bstnma.fios.verizon.net] has joined #uml
09:50<jdike-#uml->>Hi guys
09:50<DomQ-#uml->>Hi!
09:51<DomQ-#uml->>You may have noticed that I have a brand new bug report for you :)
09:53<jdike-#uml->>maybe I would if my mail server would talk to me
09:53<DomQ-#uml->>Oh.
09:53<DomQ-#uml->>You want a direct link? :)
09:53<jdike-#uml->>I suppose
09:55<DomQ-#uml->>http://kilimandjaro.dyndns.org/~dom/uml/bugreport-gdb-uml64
09:57<jdike-#uml->>this is fixed
09:57<DomQ-#uml->>Where?
09:57<jdike-#uml->>apparently in 2.6.22.9 as you noticed
09:58<jdike-#uml->>in 2.6.23 for sure
09:58<DomQ-#uml->>No, 2.6.22.9 and 2.6.23 only work on i386, not amd64
09:58<DomQ-#uml->>I'm double-checking to be sure...
09:58<DomQ-#uml->>SGM:/hostfs# uname -a
09:58<DomQ-#uml->>Linux SGM 2.6.23 #1 Wed Oct 24 18:07:16 CEST 2007 x86_64 GNU/Linux
09:58<jdike-#uml->>they should all work on x86_64
09:58<DomQ-#uml->>SGM:/hostfs# gdb /bin/ls
09:58<DomQ-#uml->>GNU gdb 6.4.90-debian
09:59<DomQ-#uml->>(blah blah blah no warranty blah)
09:59<DomQ-#uml->>[42949516.630000] Kernel panic - not syncing: get_fpregs
09:59<jdike-#uml->>hm
09:59<DomQ-#uml->>Host is 2.6.18-4-amd64 (Debian etch)
09:59<jdike-#uml->>it's fixed somewhere because I remember fixing it
10:00<jdike-#uml->>I wonder if it was in the patches that I held for 2.6.24 and which made 2.6.24-rc1
10:00<jdike-#uml->>if so, that's a good -stable candidate
10:00<DomQ-#uml->>I'll try 2.6.24-rc1 now.
10:02<DomQ-#uml->>BTW I was using gdb because I'm chasing another bug.
10:03<DomQ-#uml->>ldconfig in an amd64 UML says:
10:03<DomQ-#uml->>ldconfig: /usr/local/compil-Streamcore/binutils/etch-2.17-3_amd64/lib/libopcodes-2.17.so is not an ELF file - it has the wrong magic bytes at the start.
10:04<DomQ-#uml->>But that cannot be true, as the host doesn't say that (exact same ldconfig, which is statically linked, and exact same libopcodes-2.17.so)
10:04<jdike-#uml->>what does file say about that?
10:04<DomQ-#uml->>SGM:/hostfs# file /usr/local/compil-Streamcore/binutils/etch-2.17-3_amd64/lib/libopcodes-2.17.so
10:04<DomQ-#uml->>/usr/local/compil-Streamcore/binutils/etch-2.17-3_amd64/lib/libopcodes-2.17.so: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), stripped
10:04<DomQ-#uml->>Everything looks normal
10:04<jdike-#uml->>so they have the same md5sum?
10:04<DomQ-#uml->>Yep.
10:04<DomQ-#uml->>Also ldconfig -v works (!)
10:04<DomQ-#uml->>I noticed that ldconfig uses mmap to read the files.
10:04<DomQ-#uml->>Does this ring a bell?
10:05<jdike-#uml->>this is on a hostfs mount?
10:05<DomQ-#uml->>No.
10:06<jdike-#uml->>hm
10:06<jdike-#uml->>md5sum and mmap are both reading the file from disk
10:07<jdike-#uml->>it's kind of hard to see how one will see different bytes than the other
10:07<jdike-#uml->>FWIW the get_fpregs thing is fixed in -rc1
10:07<DomQ-#uml->>I notice that the error is always on the *first* .so that ldconfig tries to read.
10:08<jdike-#uml->>so it moves around?
10:08<DomQ-#uml->>Depends. When the error occurs, it's on the first .so; but in other situations, it doesn't happen at all.
10:08<DomQ-#uml->>eg I removed libopcodes, now the error is on libbfd-2.17.so
10:09<jdike-#uml->>then, can you strace ldconfig?
10:09<DomQ-#uml->>Yes, but not gdb it yet :-)
10:09<DomQ-#uml->>I see an mmap.
10:09<jdike-#uml->>with -s 1024 so we can see what data it's getting from the filesystem?
10:09<DomQ-#uml->>and the error message get write()en right away.
10:09<jdike-#uml->>except mmap won't show that
10:10<DomQ-#uml->>True.
10:10<jdike-#uml->>so it's basically mmap(); write("ACK!"); exit()?
10:10<DomQ-#uml->>No, it goes on ldconfig'ing the rest of the disk, and all goes well ever after.
10:11<DomQ-#uml->>I have:
10:11<DomQ-#uml->>open("/usr/local/compil-Streamcore/binutils/etch-2.17-3_amd64/lib/libopcodes-2.17.so", O_RDONLY) = 4
10:11<DomQ-#uml->>fstat(4, {st_mode=S_IFREG|0644, st_size=155912, ...}) = 0
10:11<DomQ-#uml->>mmap(NULL, 155912, PROT_READ, MAP_SHARED, 4, 0) = 0x40000000
10:11<DomQ-#uml->>write(2, "ldconfig: ", 10) = 10
10:11<DomQ-#uml->>write(2, "/usr/local/compil-Streamcore/bin"..., 143) = 143
10:11<DomQ-#uml->>write(2, "\n", 1) = 1
10:11<DomQ-#uml->>the long "write" is the error message.
10:12<jdike-#uml->>right
10:13<jdike-#uml->>ooh
10:13<jdike-#uml->>happens here too
10:17<DomQ-#uml->>I'm looking at the source to see whether the "error at first file" phenomenon is caused by ldconfig refraining from emitting the same error message twice.
10:18<jdike-#uml->>doesn't look like it
10:20<DomQ-#uml->>You beat me at it
10:21<jdike-#uml->>#define ELFMAG "\177ELF"
10:22<jdike-#uml->>od -xc /usr/lib64/mysql/libmysqlclient.so.15.0.0 | head
10:22<jdike-#uml->>0000000 457f 464c 0102 0001 0000 0000 0000 0000
10:22<jdike-#uml->> 177 E L F 002 001 001 \0 \0 \0 \0 \0 \0 \0 \0 \0
10:22<jdike-#uml->>kinda looks right to me
10:22<DomQ-#uml->>yeah, libmysqlclient. The first time around I had the issue on that one as well.
10:22<DomQ-#uml->>Does "ldconfig -v" work for you?
10:23<jdike-#uml->>except for some duplicate directories and some broken symlinks, yes
10:27<DomQ-#uml->>Oh noes, 2.6.24-rc1 doesn't compile!
10:27<DomQ-#uml->>arch/um/drivers/ubd_kern.c: In function ‘do_ubd_request’:
10:27<DomQ-#uml->>arch/um/drivers/ubd_kern.c:1118: error: implicit declaration of function ‘sg_page’
10:27<DomQ-#uml->>arch/um/drivers/ubd_kern.c:1118: warning: passing argument 6 of ‘prepare_request’ makes pointer from integer without a cast
10:28<jdike-#uml->>there's a patch for that
10:28<jdike-#uml->>+#include "linux/scatterlist.h"
10:28<Magotari_-#uml->>There is plenty breakage all around that I see, not just UML. I ran about 40 randconfig builds on ARCH=x86, and more than half failed.
10:28<jdike-#uml->>hehe
10:29<Magotari_-#uml->>I wrote a python script to do it for me, but I forgot the increment a counter... All .configs from bad builds overwritten... *sigh*
10:31<jdike-#uml->>http://bash.org/?605501
10:32<Magotari_-#uml->>Ouch!
10:33<DomQ-#uml->>I am reminded of the Hitchhiker's Guide...
10:34<Magotari_-#uml->>btw, jdike, I think we should do something about SMP. You can pick it in Kconfig, but it won't build. Maybe make it depend on BROKEN?
10:34<jdike-#uml->>I thought it did depend on BROKEN
10:34<Magotari_-#uml->>Nope.
10:34<Magotari_-#uml->>Want a patch? ;)
10:34<DomQ-#uml->>I see the gcc command line goes -U__x86_64__
10:35<DomQ-#uml->>and struct user_desc in include/asm-um/arch/ldt.h #ifdef's on it
10:35<DomQ-#uml->>So what is the correct symbol to check for these days?
10:36<DomQ-#uml->>#ifdef __x86_64 maybe?
10:37<jdike-#uml->>dunno
10:37<Magotari_-#uml->>Actually, maybe nesting on BROKEN too?
10:37<jdike-#uml->>Al Viro had a bunch of fixes which fiddle the -U__i386
10:37<jdike-#uml->>so maybe something similar is needed for x86_64
10:38<DomQ-#uml->>Well apparently it is
10:38<DomQ-#uml->>I can send you a patch for that as well
10:38<DomQ-#uml->>jdike: I feel that the patch management administratrivia takes a heavy toll on your time... Am I right?
10:39<jdike-#uml->>not really
10:39<DomQ-#uml->>well good, I for one am not quite up to speed with that yet
10:40<DomQ-#uml->>So are you interested in a "get 2.6.24-rc1 to compile" patch?
10:41<jdike-#uml->>on i386 or x86_64?
10:41<Magotari_-#uml->>jdike: Build breakage: http://pastebin.com/m20891b2c
10:41<DomQ-#uml->>x86_64
10:41<jdike-#uml->>yes
10:41<jdike-#uml->>I just fired off a build there
10:41<Magotari_-#uml->>Want .config?
10:42<jdike-#uml->>was that the only problem?
10:42<jdike-#uml->>and you have Al Viro's UML build patch?
10:42<Magotari_-#uml->>Ah. That would explain a bit.
10:42<Magotari_-#uml->>Let me get it. :/
10:42<Magotari_-#uml->>Sorry.
10:43<jdike-#uml->>np
10:43<jdike-#uml->>there are patches flying around everywhere
10:44<DomQ-#uml->>indeed :-)
10:44<jdike-#uml->>I have a rolled-up make-rc1-build-on-i386 patch if you need it
10:44<Magotari_-#uml->>See, I am really eager to help, however I can. And I am not the smartest person out there, nor very well organized. So I make mistakes often.
10:44<jdike-#uml->>hm
10:44<Magotari_-#uml->>I would not say no to a patch, at all.
10:44|-|Magotari_ changed nick to Magotari
10:44<jdike-#uml->>the x86_64 build seems to be doing OK
10:45<Magotari-#uml->>Looking for the Al Viro thing, but not on lkml.
10:45<jdike-#uml->>http://pastebin.com/m681002ec
10:45<jdike-#uml->>that's everything
10:46<Magotari-#uml->>Got it.
10:49<Magotari-#uml->>I love ccache.
10:50<jdike-#uml->>with that patch, x86_64 builds and runs
10:50<jdike-#uml->>Kernel 2.6.24-rc1 on an x86_64
10:52<Magotari-#uml->>Seems like it builds here now too.
10:52<Magotari-#uml->>Two strikes against me in two days. Argh.
10:53<DomQ-#uml->>Same here too
10:53<DomQ-#uml->>gdb still does not work, but at least the kernel survives
10:56<jdike-#uml->>gdb seems OK here
10:57<jdike-#uml->>gdb ls, run seems to work
10:57<DomQ-#uml->>Hmm.
10:57<jdike-#uml->>Error while reading shared library symbols:
10:57<jdike-#uml->>Couldn't write debug register: Input/output error.
10:57<jdike-#uml->>there is that
10:57<jdike-#uml->>which doesn't happen on the host
10:59<jdike-#uml->>no symbols in ldconfig
10:59<jdike-#uml->>sorta crimps my style
11:00<DomQ-#uml->>gdb gives me:
11:00<DomQ-#uml->>[Thread debugging using libthread_db enabled]
11:00<DomQ-#uml->>Error while reading shared library symbols:
11:00<DomQ-#uml->>Cannot find new threads: generic error
11:00<DomQ-#uml->>Cannot find user-level thread for LWP 1142: generic error
11:00<jdike-#uml->>what happens on the host?
11:01<DomQ-#uml->>It works.
11:04<jdike-#uml->>so none of these nasty errors?
11:04<DomQ-#uml->>No, the host works fine but gdb does nothing in the guest
11:05<DomQ-#uml->>ls is not even run (at least I don't see the result)
11:06<jdike-#uml->>how do you use yumdownloader?
11:06<jdike-#uml->>yumdownloader --source glibc-2.4-11
11:06<jdike-#uml->>No Match for argument glibc-2.4-11
11:06<jdike-#uml->>ldconfig is in libc unfortunately
11:07<DomQ-#uml->>Sorry, I don't know yumdownloader
11:31|-|arun [~arun@yktgi01e0-s5.watson.ibm.com] has joined #uml
11:44|-|tyler29 [~tyler@ARennes-257-1-73-102.w81-53.abo.wanadoo.fr] has quit [Ping timeout: 480 seconds]
11:56|-|tyler29 [~tyler@86.210.21.254] has joined #uml
12:00|-|hfb [~hfb@pool-71-106-219-180.lsanca.dsl-w.verizon.net] has joined #uml
12:11<jdike-#uml->>panicectomy time
12:12<Magotari-#uml->>Cutting of panics?
12:13<jdike-#uml->>yup
12:13<jdike-#uml->>the default action when something in libc fails is to panic
12:14<jdike-#uml->>but the kernel is still perfectly healthy - just the one process can't continue
12:14<jdike-#uml->>crashme demonstrates this in a couple of ways
12:23<Magotari-#uml->>Yeah, vicious tool that.
12:23<Magotari-#uml->>I am playing with a similar idea, but more directed at the kernel, namely sending only random syscalls.
12:24<Magotari-#uml->>Maybe I will write it for a C project... I do need to learn the damn thing. The skill is getting usable, slowly.
12:24<Magotari-#uml->>I am damn old to be learning C at 20, but... Better late than never.
12:25|-|darious12 [~darius@athedsl-302112.home.otenet.gr] has joined #uml
12:27<jdike-#uml->>that's about when I learned C, I think
12:27<Magotari-#uml->>Oh. I thought you had to start early... 15 or less.
12:28[~]Magotari #uml lets loose his randconfig monster on uml.#uml-> lets loose his randconfig monster on uml.
12:30|-|ram [~ram@pool-71-117-247-93.ptldor.fios.verizon.net] has joined #uml
12:32|-|tyler29 [~tyler@86.210.21.254] has quit [Ping timeout: 480 seconds]
12:34<jdike-#uml->>Do you have my current config fixes?
12:35<jdike-#uml->>otherwise 7/8 of randconfig will fail, due to SWAP, TCP, and PRINTK
12:35<Magotari-#uml->>I don't think so. But don't worry, I took that into account.
12:35<Magotari-#uml->>The program will sort the fails, depending on cause.
12:35<Magotari-#uml->>So if there is something to find, it won't vanish because of being lost in a crowd of other things.
12:36<Magotari-#uml->>That being said, I would love a patch too.
12:36<Magotari-#uml->>Most of randconfig will actually fail because of SLIRP and VDE.
12:36<Magotari-#uml->>Those are really easy to select by randconfig and I don't want to install the software for them.
12:37|-|ram_ [~ram@pool-71-117-247-93.ptldor.fios.verizon.net] has joined #uml
12:37|-|ram [~ram@pool-71-117-247-93.ptldor.fios.verizon.net] has quit [Read error: Connection reset by peer]
12:42|-|ram [~ram@pool-71-117-247-93.ptldor.fios.verizon.net] has joined #uml
12:42|-|ram_ [~ram@pool-71-117-247-93.ptldor.fios.verizon.net] has quit [Read error: Connection reset by peer]
12:44|-|tyler29 [~tyler@ARennes-257-1-74-55.w81-53.abo.wanadoo.fr] has joined #uml
12:50[~]jdike #uml builds a sparc toolchain#uml-> builds a sparc toolchain
12:51[~]jdike #uml prepares to hug Dan Kegel's crosstools, if not Dan himself#uml-> prepares to hug Dan Kegel's crosstools, if not Dan himself
13:15<kokoko1-#uml->>heh
13:25<kokoko1-#uml->>http://oink.cd/ <--- lol I shoudn't be seeding ;)
13:25<kokoko1-#uml->>no freedom left :-s
13:28<Magotari-#uml->>oink.cd?
13:28<Magotari-#uml->>What is that?
13:29<Magotari-#uml->>Aha. Illegal music. Ok. Gotcha.
13:29<kokoko1-#uml->>heh yeah
13:56|-|DomQ [~DomQ@streamcore.pck.nerim.net] has quit [Ping timeout: 480 seconds]
14:11<jdike-#uml->>that worked really well
14:12<jdike-#uml->>Dan doesn't get hugged though
14:20<peterz-#uml->>you got sparc32 build?
14:20<peterz-#uml->>or just sparc64
14:23<jdike-#uml->>sparc32
14:23<jdike-#uml->>The offending comment just says sparc without being specific
14:23<jdike-#uml->> * so leave page_cache_release and release_pages undeclared... */
14:24<jdike-#uml->>oops
14:24<jdike-#uml->> /* only sparc can not include linux/pagemap.h in this file
14:24<jdike-#uml->> * so leave page_cache_release and release_pages undeclared... */
14:24<jdike-#uml->>that began with a /
14:24<jdike-#uml->>What I want to do is include linux/pagemap.h in this file
14:24<jdike-#uml->>so I need to see what sparc's problem is, exactly
14:32<jdike-#uml->>sparc's problem is the build breaks horribly
14:44|-|tyler29 [~tyler@ARennes-257-1-74-55.w81-53.abo.wanadoo.fr] has quit [Ping timeout: 480 seconds]
14:50|-|Nem^ [~Nem@dslb-084-056-252-225.pools.arcor-ip.net] has quit [Remote host closed the connection]
14:55<Magotari-#uml->>rc1 is in pretty good shape. All fails are: VDE SWAP SMP PRINTK, so nothing really evil or unexpected.
14:58<jdike-#uml->>cool
15:00<Magotari-#uml->>Yeah. Next on the agenda: Analysing the .config files in such a way to find the offending option. While we don't need it now, maybe in the future to make things easier.
15:00|-|tyler29 [~tyler@ARennes-257-1-158-74.w86-214.abo.wanadoo.fr] has joined #uml
15:05|-|cl4sh [~cl4sh@syf.ds.pg.gda.pl] has joined #uml
15:05<Magotari-#uml->>Hello, cl4sh.
15:05<cl4sh-#uml->>hi
15:08<cl4sh-#uml->>i want to ask how to mount files too see it under uml ?
15:08<Magotari-#uml->>Hmm... You mean hostfs?
15:08<Magotari-#uml->>Or just a single file via an udb* device?
15:08<cl4sh-#uml->>by mconsole?
15:09<Magotari-#uml->>Oh. I know you can use an ubd* device from mconsole... Not sure about hostfs.
15:10<Magotari-#uml->>You just attach a device ubd*, where * is a free device letter. ubdb=/home/karol/linux.tar
15:10<Magotari-#uml->>You can then dd it from the device to a file on the guest.
15:10<Magotari-#uml->>Or even tar from the device.
15:11<Magotari-#uml->>Now, let me check into hostfs from mconsole.
15:11<jdike-#uml->>no need
15:11<jdike-#uml->>just mount from inside UML works
15:11<Magotari-#uml->>UML# mount none /host -t hostfs
15:11<Magotari-#uml->>Yeah, the problem being is, we want from mconsole.
15:12<jdike-#uml->>why?
15:12<Magotari-#uml->>I guess with the mconsole exec patch...
15:12<jdike-#uml->>right
15:12<Magotari-#uml->>No idea, but that was the question.
15:12<Magotari-#uml->> cl4sh> by mconsole?
15:12<Magotari-#uml->>Unless I misunderstood.
15:12<Magotari-#uml->>Phone time again.
15:12<cl4sh-#uml->>maybe ill try jdike trick :P
15:13<huslu-#uml->>uml_mconsole config ubdb=<something> ?
15:16<huslu-#uml->>hmm no, that wouldn't work perhaps
15:17<cl4sh-#uml->>df -f told me that ive hot hostfs mounted but nothing is insisdde
15:17<cl4sh-#uml->>it should be my home directory
15:17<jdike-#uml->>mount says the same thing?
15:18<cl4sh-#uml->>none on /mnt/hostfs type hostfs
15:18|-|mgross [~mgross@jffwprtest.jf.intel.com] has joined #uml
15:18<cl4sh-#uml->>how to do that by mconsole
15:21<jdike-#uml->>and there's nothing in /mnt/hostfs?
15:22<cl4sh-#uml->>yes
15:22<jdike-#uml->>hm
15:22<cl4sh-#uml->>but theres comment like rw,/home/qik/.vnuml/simulations/tutorial-u1/vms/uml3/hostfs
15:22<jdike-#uml->>what version of UML?
15:22<cl4sh-#uml->>maybe i should put something into this directory ?
15:23<jdike-#uml->>no
15:23<jdike-#uml->>what was the mount command, exactly?
15:24|-|mgross [~mgross@jffwprtest.jf.intel.com] has quit [Quit: Leaving]
15:24<Magotari-#uml->>huslu: I think it would work. You need the umid too though.
15:24<cl4sh-#uml->>ok it works by copy
15:24|-|tyler29 [~tyler@ARennes-257-1-158-74.w86-214.abo.wanadoo.fr] has quit [Ping timeout: 480 seconds]
15:25<cl4sh-#uml->>into this directory about which i was said
15:26<huslu-#uml->>Magotari: oh yes umid also.
15:41|-|tyler29 [~tyler@ARennes-257-1-166-43.w86-214.abo.wanadoo.fr] has joined #uml
15:45|-|kos_tom [~thomas@col31-3-82-247-183-72.fbx.proxad.net] has joined #uml
16:08|-|linbot [~supybot@ns.theshore.net] has quit [Ping timeout: 480 seconds]
16:08|-|tasaro [~tom@ns.theshore.net] has quit [Ping timeout: 480 seconds]
16:16|-|VS_ChanLog [~stats@ns.theshore.net] has joined #uml
16:17|-|linbot [~supybot@ns.theshore.net] has joined #uml
16:18|-|caker [~caker@caker.netrep.oftc.net] has joined #uml
16:18|-|tasaro [~tom@ns.theshore.net] has joined #uml
16:18|-|krau [~cktakahas@200.184.118.132] has quit [Quit: Varei!!!]
16:23|-|krau [~cktakahas@200.184.118.132] has joined #uml
16:31|-|cl4sh [~cl4sh@syf.ds.pg.gda.pl] has quit [Quit: leaving]
16:32<Magotari-#uml->>Well, thirty rounds of randconfig later here are some fun statistics: Build was fine 8/30 times. Five kinds of build failures, all either fixed, BROKEN or lack of userspace libs on my part. No SLIRP failure, which is puzzling, but whatever... Maybe I got it installed?
16:32|-|dsoul_ changed nick to dsoul
16:34<Magotari-#uml->>Really, rc1 is in amazing shape, considering the architecture merge and all. At least from the "it builds" point of view.
16:35|-|besonen_mobile__ [~besonen_m@71-220-227-56.eugn.qwest.net] has joined #uml
16:35|-|besonen_mobile_ [~besonen_m@71-220-227-56.eugn.qwest.net] has quit [Read error: Connection reset by peer]
16:36<jdike-#uml->>I don't think SLIRP needs anything installed
16:37<Magotari-#uml->>Really? I am quite sure it was giving me a build failure before. Well, no matter now, I guess.
16:37<Magotari-#uml->>Enough randconfigs, time for the kilogram and crashme and the benchmarks.
16:45<Magotari-#uml->>Hmm... Does anyone know a non-Linux POSIX system which has ext3 as the default partition type?
17:02|-|dan1 [~dang@aa-redwall.nexthop.com] has quit [Quit: Leaving.]
17:02<Magotari-#uml->>Hmm... Strange... I gave UML exactly 10000000 bytes. "dd if=/dev/mem of=file" gives me "9999872 bytes (10 MB) copied" It also prints "dd: reading '/dev/mem/': Bad address"
17:03<Magotari-#uml->>That is with my failsafe kernel, because the new one won't boot. Maybe I misconfigured something?
17:06<Magotari-#uml->>Hmm. It won't boot in 10 megs of ram now. I guess it did not like the 2^21 size kernel log?
17:09|-|tyler29 [~tyler@ARennes-257-1-166-43.w86-214.abo.wanadoo.fr] has quit [Ping timeout: 480 seconds]
17:12<jdike-#uml->>memory is measured in pages
17:13<Magotari-#uml->>Yeah, that explains it. Thanks.
17:17<newbie-#uml->>debuging uml guest fc3 root image running under host kernel version 2.6.22.9-91.fc7 - Hang during "Initializing hardware" - just added debug statements to sysinit, and find it is hanging in the call to kmodules. Strange... Any idea what might be causing that? I have no network access in the guest yet - I explicitly have disabled it and a number of services likely to need it in an effort to avoid issues like this.
17:19<newbie-#uml->>my problem must be something in the root image I'm using - since the pristine root image I downloaded as a sanity check seems to boot fine
17:19<newbie-#uml->>In addition, I should note I am doing this on a 64bit machine
17:20<newbie-#uml->>I beleive it was jdike yesterday who mentioned some 64bit issues yesterday and that it would be best to try under 2.6.23 (host kernel)
17:20<newbie-#uml->>jdike: Do you know of any 64 bit issues with 2.6.22?
17:20<newbie-#uml->>jdike: HOST kernels
17:20<jdike-#uml->>no
17:21<jdike-#uml->>afaik newer host kernels are good
17:22<newbie-#uml->>jdike: hmmm...ok... Still think it's work me finding a 2,6.23 system (I think I can get access to a Xen VM to try running UML in - but I'd rather not add a layer of potential complexity) ?
17:22<newbie-#uml->>err work==> worth
17:22<jdike-#uml->>2.6.22 is fine if you have one of those
17:22<newbie-#uml->>ok so my problem must be something else.
17:23<newbie-#uml->>the kmodule call from sysinit not only does not work - it never seems to return - I put echo statements on both sides of it
17:25<jdike-#uml->>you have it narrowed down to one line of shell?
17:26<newbie-#uml->>yes
17:26<newbie-#uml->>just found a potential lead on the problem in google - need to look at something - back soon
17:29<newbie-#uml->>anyone know if I need /etc/sysconfig/hwconf or if it can auto-recreate itself if I remove it?
17:30<newbie-#uml->>kmodules apparently consults this file
17:31|-|tyler29 [~tyler@ARennes-257-1-84-121.w86-199.abo.wanadoo.fr] has joined #uml
17:36|-|cl4sh [~cl4sh@syf.ds.pg.gda.pl] has joined #uml
17:38<cl4sh-#uml->>Magotari: seems that vnuml cant take asterisk :/
17:40|-|kos_tom [~thomas@col31-3-82-247-183-72.fbx.proxad.net] has quit [Quit: I like core dumps]
17:41<cl4sh-#uml->>Magotari: if i couldnt do this to the weekend then i would think about ne vm
17:41<cl4sh-#uml->>Magotari: good night
17:41|-|cl4sh [~cl4sh@syf.ds.pg.gda.pl] has quit [Quit: leaving]
17:42<Magotari-#uml->>*sigh*
17:42<Magotari-#uml->>I was on the phone, could not react any faster.
17:43<Magotari-#uml->>What saddens me is that UML is not widely known. People at my school thought it got removed from the kernel ages ago. And the competition is strong.
17:45<Magotari-#uml->>Now, UML should take asterisk just fine. Gotta get that Gentoo system up and running again, emerge time.
17:56<huslu-#uml->>btw, is there a good howto how to make a minimal centos filesystem to go with uml?
17:58<Magotari-#uml->>I don't know that. I saw some tools to make a rootfs out of rpms though. Not sure if they are good anymore, but if you look around the uml website you will find the directions.
17:59<huslu-#uml->>in debian it's easy with rootstrap which uses debootstrap. other distros are more mysterious for me.
17:59<caker-#uml->>huslu: install onto a physical machine and copy it off :)
18:00<Magotari-#uml->>Or use QEMU.
18:00<jdike-#uml->>with RPM-based distros, you can install yum and fedora-release RPMs into a directory, and then upgrade it
18:02<huslu-#uml->>ya, should try it out.
18:05<Magotari-#uml->>jdike: There is a problem I think I should (finally) report. I am a fan of the ssl channel. ssl=port:9000. The problem is that sometimes when UML crashes, the port stays busy. Next time I try to launch something it gives off a lot of messages that it cannot use the port, and boots without.
18:05<Magotari-#uml->>killall -9 linux does not help.
18:05<Magotari-#uml->>Only killall port_helper or however the program is called clears the port.
18:05<jdike-#uml->>right
18:06<jdike-#uml->>if UML crashes, how much cleanup do you expect?
18:06<Magotari-#uml->>As much as possible and within reason.
18:07<Magotari-#uml->>I used to use ssl as the only channel. I got locked out quite a few times, had to cad the system from mconsole. It was frustrating, but not critical.
18:08<Magotari-#uml->>It sure prints a lot of warnings, maybe not booting could be an idea here? I really don't know what to think about it.
18:09<jdike-#uml->>no, it's not fatal
18:10<jdike-#uml->>the one thing that might work is that the port-helper could detect UML going away, and exiting
18:10<Magotari-#uml->>I thought about it, that was my only idea. UML maybe could signal it somehow, but kinda hard to do much when crashing...
18:15<jdike-#uml->>no
18:16<jdike-#uml->>if there's a stream socket between them (and I don't remember), then port-helper will see it close when UML dies
18:16<Magotari-#uml->>So a matter of checking if the socket is closed? Sounds fairly simple.
18:17<Magotari-#uml->>I would normally ask for a chance to patch it, but after my past experience with volounteering, I shall just not ask for trouble.
18:22<jdike-#uml->>you don't need to ask
18:22<jdike-#uml->>you just do
18:24<Magotari-#uml->>And I get to keep my disaster news to myself. Sounds good.
18:59|-|tyler29 [~tyler@ARennes-257-1-84-121.w86-199.abo.wanadoo.fr] has quit [Ping timeout: 480 seconds]
19:00|-|jdike [~jdike@pool-71-248-190-161.bstnma.fios.verizon.net] has quit [Quit: Leaving]
19:12|-|hfb [~hfb@pool-71-106-219-180.lsanca.dsl-w.verizon.net] has quit [Quit: Leaving]
19:12|-|mgross [~mgross@jffwprtest.jf.intel.com] has joined #uml
20:20|-|aroscha [~aroscha@d-252.dsl.tu-graz.ac.at] has joined #uml
20:28|-|mgross [~mgross@jffwprtest.jf.intel.com] has quit [Quit: Leaving]
20:32|-|aroscha [~aroscha@d-252.dsl.tu-graz.ac.at] has quit [Read error: Connection reset by peer]
---Logclosed Wed Oct 24 21:24:34 2007
---Logopened Wed Oct 24 21:24:39 2007
21:24|-|mikegrb [~michael@mail.thegrebs.com] has joined #uml
21:26|-|Kanal #uml zsynchronizowany w 103 sekundy
22:32|-|mgross [~mgross@71-34-106-244.ptld.qwest.net] has joined #uml
23:34|-|mgross [~mgross@71-34-106-244.ptld.qwest.net] has quit [Ping timeout: 480 seconds]
23:59|-|VS_ChanLog [~stats@ns.theshore.net] has left #uml [Rotating Logs]
23:59|-|VS_ChanLog [~stats@ns.theshore.net] has joined #uml
---Logclosed Thu Oct 25 00:00:41 2007