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

---Logopened Tue Oct 23 00:00:22 2007
01:45|-|peterz [~peterz@i55087.upc-i.chello.nl] has quit [Ping timeout: 480 seconds]
02:47|-|Baltam8 [~WIKIMOKI@tor-irc.dnsbl.oftc.net] has quit [Remote host closed the connection]
02:57|-|Baltam8 [~WIKIMOKI@tor-irc.dnsbl.oftc.net] has joined #uml
03:28|-|cl4sh [~cl4sh@syf.ds.pg.gda.pl] has joined #uml
03:28<cl4sh-#uml->>hi all
03:46|-|aroscha [~aroscha@chello213047053193.30.11.tuwien.teleweb.at] has joined #uml
03:47<Magotari-#uml->>Don't tell me my favourite bit of software broke again?
04:04<cl4sh-#uml->>:P
04:04<cl4sh-#uml->>Magotari: i waiting for jdike
04:05<cl4sh-#uml->>the problem is still the same as yesterday
04:06<Magotari-#uml->>Ah. Right.
04:06<Magotari-#uml->>He is really good, he make UMl.
04:08<cl4sh-#uml->>i nkow
04:08<cl4sh-#uml->>i siil cant creater some of interfaces
04:09<Magotari-#uml->>Yeah, that ain't great.
04:09<Magotari-#uml->>And I am still sick, spending ages playing around with UMLs.
04:11<cl4sh-#uml->>at least You make something interesting and creative
04:13<Magotari-#uml->>Not sure if creative. This is just a big bughunt.
04:13<Magotari-#uml->>Trying to break something via /proc/
04:14<Magotari-#uml->>There was a very interesting bug which happens if you do "swapon /dev/kmem" as root.
04:14<Magotari-#uml->>On the host it will be refused, but UML will hang.
04:14<Magotari-#uml->>I reported it a while back, but funny to see it.
04:15<cl4sh-#uml->>uhm
04:15<cl4sh-#uml->>this is hi level things for me :pp
04:16<Magotari-#uml->>Just do stuff which no one thought of before, you will find bugs everywhere. Not high level at all.
04:17<cl4sh-#uml->>:)
04:17<cl4sh-#uml->>yes You're right
04:24<cl4sh-#uml->>Magotari: this is great prbolem with eth interface creating on ost side
04:24<cl4sh-#uml->>guest side
04:32<Magotari-#uml->>Yeah, it is crippling to the core functionality.
04:33<cl4sh-#uml->>i must run it by kernel from vnuml site
04:45|-|tyler29 [~tyler@ARennes-257-1-41-139.w81-53.abo.wanadoo.fr] has joined #uml
04:49|-|aroscha [~aroscha@chello213047053193.30.11.tuwien.teleweb.at] has quit [Quit: aroscha]
05:37|-|cl4sh [~cl4sh@syf.ds.pg.gda.pl] has quit [Quit: Changing server]
05:41|-|cl4sh [~cl4sh@syf.ds.pg.gda.pl] has joined #uml
05:47|-|cl4sh [~cl4sh@syf.ds.pg.gda.pl] has quit [Quit: leaving]
06:16|-|aroscha [~aroscha@vie-213-235-223-240.dsl.sil.at] has joined #uml
06:33|-|cl4sh [~cl4sh@syf.ds.pg.gda.pl] has joined #uml
06:33|-|cl4sh [~cl4sh@syf.ds.pg.gda.pl] has quit []
06:38|-|tyler29 [~tyler@ARennes-257-1-41-139.w81-53.abo.wanadoo.fr] has quit [Ping timeout: 480 seconds]
06:38|-|aroscha [~aroscha@vie-213-235-223-240.dsl.sil.at] has quit [Ping timeout: 480 seconds]
06:48|-|tyler29 [~tyler@ARennes-257-1-85-201.w86-199.abo.wanadoo.fr] has joined #uml
07:06|-|cl4sh [~cl4sh@syf.ds.pg.gda.pl] has joined #uml
07:07<cl4sh-#uml->>Magotari: everything work without problem under ubuntu :P
07:12|-|cl4sh [~cl4sh@syf.ds.pg.gda.pl] has quit [Quit: Lost terminal]
07:35|-|aroscha [~aroscha@vie-213-235-223-240.dsl.sil.at] has joined #uml
07:45|-|dang [~dang@nemesis.fprintf.net] has quit [Quit: Leaving.]
07:46|-|tyler29 [~tyler@ARennes-257-1-85-201.w86-199.abo.wanadoo.fr] has quit [Ping timeout: 480 seconds]
07:47|-|aroscha [~aroscha@vie-213-235-223-240.dsl.sil.at] has quit [Read error: Connection reset by peer]
07:47|-|aroscha [~aroscha@vie-213-235-223-240.dsl.sil.at] has joined #uml
07:59|-|tyler29 [~tyler@ARennes-257-1-71-74.w81-53.abo.wanadoo.fr] has joined #uml
08:03|-|aroscha [~aroscha@vie-213-235-223-240.dsl.sil.at] has quit [Ping timeout: 480 seconds]
08:07|-|cl4sh [~cl4sh@syf.ds.pg.gda.pl] has joined #uml
08:08|-|dang [~dang@aa-redwall.nexthop.com] has joined #uml
08:11<Magotari-#uml->>cl4sh: Great that it does work fine at last in one place.
08:11<cl4sh-#uml->>Magotari: :)
08:12<cl4sh-#uml->>Magotari: i must install flux under ubuntu and tunne it on to look like my gentoo :P
08:12<cl4sh-#uml->>cuz i cant work
08:18|-|aroscha [~aroscha@86.59.55.206] has joined #uml
09:13|-|cl4sh [~cl4sh@syf.ds.pg.gda.pl] has quit [Quit: Lost terminal]
09:16|-|dang [~dang@aa-redwall.nexthop.com] has quit [Remote host closed the connection]
09:22|-|dang [~dang@aa-redwall.nexthop.com] has joined #uml
09:32|-|DomQ [~DomQ@streamcore.pck.nerim.net] has joined #uml
09:32<DomQ-#uml->>Hi UML people
09:33<DomQ-#uml->>I have a x86-64 UML and I want to run i386 programs in it
09:33<DomQ-#uml->>(Yeah I know, who doesn't...)
09:34<DomQ-#uml->>Is it possible to use a nested UML for this purpose?
09:34<Magotari-#uml->>:/
09:34<DomQ-#uml->>iow a "cross-UML" built for a x86-64 guest, but implementing an i386 host.
09:34<Magotari-#uml->>DomQ: You don't need a cross uml.
09:35<Magotari-#uml->>You can run a 32bit kernel and fs on a 64bit system.
09:35<Magotari-#uml->>Just grab the kernel and the rootfs from the website, they will work fine.
09:35|-|jdike [~jdike@pool-71-248-190-161.bstnma.fios.verizon.net] has joined #uml
09:35<jdike-#uml->>Hi guys
09:35<Magotari-#uml->>I suppose it would work in a nest, but really... why?
09:35<Magotari-#uml->>Hey, jdike.
09:36<DomQ-#uml->>Magotari: I use UML as a way to standardize a build toolchain.
09:36<DomQ-#uml->>Everybody mounts the UML image RO over the network, gets a COW going on her desktop,
09:37<DomQ-#uml->>and proceeds to checkout and build the software.
09:37<Magotari-#uml->>Aha. So it is needed.
09:37<Magotari-#uml->>Well, I don't see why it would not work. Try it. jdike knows for sure.
09:38<Magotari-#uml->>It is about a nested 32bit uml inside a 64bit uml, yes?
09:38<DomQ-#uml->>Yes.
09:38<jdike-#uml->>nesting doesn't work right now
09:39<DomQ-#uml->>jdike: thanks :/
09:39<jdike-#uml->>no fundamental problems - just a couple things that need to be fixed
09:39<jdike-#uml->>and I haven't sat down and fixed them
09:39<DomQ-#uml->>Maybe if I use an old version of UML ... ?
09:39<jdike-#uml->>why do you need it?
09:40<DomQ-#uml->>As I mentioned, I use UML as a way to standardize a build toolchain.
09:40<DomQ-#uml->>Folks avail themselves of the UML image, and are guaranteed to generate the same binaries from the same source down to the octet.
09:40<DomQ-#uml->>Now the problem is, my toolchain is 32 bit...
09:41<dang-#uml->>32-bit runs fine in 64-bit... Especially if you have the whole toolchain.
09:41<dang-#uml->>I do it all the time.
09:41<DomQ-#uml->>dang: yes, but in *UML* 64-bit ?
09:41<dang-#uml->>(I use a chroot to get a full 32-bit image...)
09:41<dang-#uml->>Yes, assuming you've enabled the emulation bits.
09:41<DomQ-#uml->>And... How do I go about doing just that?
09:41<Magotari-#uml->>It should work, I think.
09:42<dang-#uml->>It's the same as in a normal kernel... let me look it up.
09:42<jdike-#uml->>so nesting is really a workaround for something else that's not there
09:42<dang-#uml->>CONFIG_IA32_EMULATION
09:42<jdike-#uml->>32-bit compatibility on 64-bit
09:42<dang-#uml->>(The obvious alternative is to just create a whole 32-bit UML and have them use that, instead. I do that too)
09:44<DomQ-#uml->>dang: there doesn't seem to be a CONFIG_IA32_EMULATION option in "make menuconfig ARCH=um"
09:44<DomQ-#uml->>(Linux 2.6.22.9)
09:45<jdike-#uml->>there isn't
09:46<DomQ-#uml->>jdike: ah. I may have been lost somewhere then... (Sorry, not native speaker)
09:46<DomQ-#uml->>When you say "so nesting is really a workaround for something else that's not there", do you mean that what I'm trying to do is a good or a bad idea?
09:48<jdike-#uml->> I'm still not clear on where nesting is coming into the picture
09:48<DomQ-#uml->>jdike: I'm trying to make up for the lack of CONFIG_IA32_EMULATION by running the 32-bit tools inside a nested UML
09:49<jdike-#uml->>32-bit UML inside a 64-bit UML?
09:49<DomQ-#uml->>Hence my idea of trying to buid a "cross-UML" or something
09:49<DomQ-#uml->>Yes.
09:49<jdike-#uml->>but why not run the 32-bit UML on the host?
09:50<DomQ-#uml->>I need 64 bit as well, unfortunately (so as to bootstrap an ISO image for x86-64: I need to run those x86-64 post-install scripts)
09:50<DomQ-#uml->>The next best thing would be to run a couple of UMLs side by side on the host: one 32-bit, the other 64-bit
09:50<jdike-#uml->>yeah
09:50<jdike-#uml->>but that's a bit cumbersome
09:51<DomQ-#uml->>yeah, especially with "make" that will have to go back and forth.
09:51|-|Netsplit charon.oftc.net <-> kinetic.oftc.net quits: ftumch
09:51|-|Netsplit over, joins: ftumch
09:52<jdike-#uml->>but you still need 32-bit compat
09:52<DomQ-#uml->>I need to run binaries of both sizes for a full build, yes:
09:52<jdike-#uml->>maybe not
09:53<DomQ-#uml->>32-bit compilers, 64-bit post-install scripts
09:53<jdike-#uml->>I was thinking a 32-bit UML had to be a 32-bit UML
09:53<jdike-#uml->>but now I'm not sure
09:53<jdike-#uml->>oop, s/UML$/binary
09:55<jdike-#uml->>but you can do make ARCH=um SUBARCH=i386 with a 64-bit toolchain
09:55<DomQ-#uml->>Let's try that!
09:55<jdike-#uml->>and end up with a 32-bit UML that's a 64-bit binary
09:55<DomQ-#uml->>I didn't know about SUBARCH.
09:56<jdike-#uml->>if you didn't, you're screwed anyway, because the nested UML will be 32-bit binary, and you'll need 32-bit compat anyway
09:58<DomQ-#uml->>Uhh. I get scary compile errors...
09:59<jdike-#uml->>yeah, I did too
10:00<jdike-#uml->>from deep inside gcc headers
10:00<DomQ-#uml->>exactly
10:00<jdike-#uml->>but it's worked for some people
10:00<DomQ-#uml->>Would those people be so kind as to provide a binary version?
10:00<jdike-#uml->>hehe
10:00<jdike-#uml->>ask on uml-user
10:01<DomQ-#uml->>The mailing list?
10:02<jdike-#uml->>yup
10:02<jdike-#uml->>also ask about toolchain versions
10:02<jdike-#uml->>since it sometimes works, it has been fixed (or broken) sometime in the past
10:02|-|aroscha [~aroscha@86.59.55.206] has quit [Ping timeout: 480 seconds]
10:03<DomQ-#uml->>jdike: thank you for your help.
10:03<jdike-#uml->>np
10:05|-|DomQ [~DomQ@streamcore.pck.nerim.net] has left #uml [bye]
10:06|-|aroscha [~aroscha@v217-189.vps.tuwien.ac.at] has joined #uml
10:08|-|aroscha [~aroscha@v217-189.vps.tuwien.ac.at] has quit []
10:17|-|aroscha [~aroscha@v217-189.vps.tuwien.ac.at] has joined #uml
10:19<kokoko1-#uml->>Hi
10:34|-|tyler29 [~tyler@ARennes-257-1-71-74.w81-53.abo.wanadoo.fr] has quit [Ping timeout: 480 seconds]
10:53|-|tyler29 [~tyler@ARennes-257-1-146-132.w86-210.abo.wanadoo.fr] has joined #uml
11:02|-|tyler29 [~tyler@ARennes-257-1-146-132.w86-210.abo.wanadoo.fr] has quit [Ping timeout: 480 seconds]
11:17|-|tyler29 [~tyler@ARennes-257-1-161-5.w86-214.abo.wanadoo.fr] has joined #uml
11:25|-|tyler29 [~tyler@ARennes-257-1-161-5.w86-214.abo.wanadoo.fr] has quit [Ping timeout: 480 seconds]
11:38|-|FooBar_ [~bbell@c-75-67-251-249.hsd1.nh.comcast.net] has joined #uml
11:39|-|tyler29 [~tyler@ARennes-257-1-163-67.w86-214.abo.wanadoo.fr] has joined #uml
11:39|-|FooBar_ changed nick to rjbell4
11:39|-|hfb [~hfb@pool-71-106-219-180.lsanca.dsl-w.verizon.net] has joined #uml
11:48<rjbell4-#uml->>I have a question about debugging user-mode linux in gdb.
11:48<rjbell4-#uml->>I'm running in SKAS0 mode.
11:48<rjbell4-#uml->>How do I debug a process that's not the current process?
11:49<rjbell4-#uml->>Do I need to attach to that process? If so, how do I figure out which one that is?
11:49<rjbell4-#uml->>task.thread.extern_pid appears only valid in tt mode.
11:49<rjbell4-#uml->>Any help would be appreciated. Thanks!
11:52<jdike-#uml->>you want to debug a process inside UML?
11:53<rjbell4-#uml->>jdike: Yes, I'd like to see where it's sleeping in the kernel.
11:53<jdike-#uml->>in that case, put a breakpoint on show_regs
11:53<jdike-#uml->>figure out the pid inside UML that you're interested in
11:53<jdike-#uml->>and uml_mconsole <umid> stack <pid>
11:54<jdike-#uml->>that will bring the process into context temporarily so you can look at its stack
11:55<rjbell4-#uml->>jdike: Yep, that seemed to work. Thanks!
12:18|-|arun [~arun@yktgi01e0-s5.watson.ibm.com] has joined #uml
12:31|-|peterz [~peterz@i55087.upc-i.chello.nl] has joined #uml
12:46|-|nessie [~nessie@lucifer.nerdfest.org] has joined #uml
12:56|-|cl4sh [~cl4sh@syf.ds.pg.gda.pl] has joined #uml
12:56<cl4sh-#uml->>jdike: hello want to say that i try to run vnuml on ubuntu and it works
12:59[~]jdike #uml is about to disappear#uml-> is about to disappear
12:59<jdike-#uml->>but that's interesting
12:59<jdike-#uml->>the hang just doesn't happen?
12:59<cl4sh-#uml->>did You find out what's wrong
12:59<jdike-#uml->>nope
12:59[~]jdike #uml disappears#uml-> disappears
12:59<cl4sh-#uml->>on ubuntu no
13:00<cl4sh-#uml->>everything works fine
13:00<cl4sh-#uml->>i can sey evry configuration i was try
13:00|-|tyler29 [~tyler@ARennes-257-1-163-67.w86-214.abo.wanadoo.fr] has quit [Ping timeout: 480 seconds]
13:13|-|tyler29 [~tyler@ARennes-257-1-16-236.w81-250.abo.wanadoo.fr] has joined #uml
13:19|-|cl4sh [~cl4sh@syf.ds.pg.gda.pl] has quit [Quit: Lost terminal]
13:30|-|dang [~dang@aa-redwall.nexthop.com] has quit [Quit: Leaving.]
13:45|-|tyler29 [~tyler@ARennes-257-1-16-236.w81-250.abo.wanadoo.fr] has quit [Ping timeout: 480 seconds]
13:49|-|aroscha [~aroscha@v217-189.vps.tuwien.ac.at] has quit [Quit: aroscha]
14:02|-|tyler29 [~tyler@ARennes-257-1-44-29.w81-53.abo.wanadoo.fr] has joined #uml
14:06|-|newbie [~jeff@ita4fw1.itasoftware.com] has joined #uml
14:07<newbie-#uml->>Hello jdike and all :-)
14:08<Magotari-#uml->>Hello, newbie.
14:09<newbie-#uml->>Hi Magorari
14:10<newbie-#uml->>I mean Mahotari (typo)
14:10<newbie-#uml->>ug still typoed
14:10<newbie-#uml->>Magotari
14:10<newbie-#uml->>there :)
14:11|-|dang [~dang@adsl-75-45-211-249.dsl.sfldmi.sbcglobal.net] has joined #uml
14:13<Magotari-#uml->>Thanks. :)
14:13<Magotari-#uml->>Don't worry, people always did this to me. Having a freak of a nick never helps, but I am attached to it.
14:13|-|tyler29 [~tyler@ARennes-257-1-44-29.w81-53.abo.wanadoo.fr] has quit [Ping timeout: 480 seconds]
14:13<Magotari-#uml->>So don't worry about it. :)
14:29|-|tyler29 [~tyler@ARennes-257-1-73-205.w81-53.abo.wanadoo.fr] has joined #uml
14:33<jdike-#uml->>back
14:38|-|kos_tom [~thomas@col31-3-82-247-183-72.fbx.proxad.net] has joined #uml
14:39<newbie-#uml->>According to the Wiki, the linux sources include an out of date version of UML, is this still the case?
14:39<newbie-#uml->>Should I be applying patches?
14:39<jdike-#uml->>kernel.org has a good UML
14:40<newbie-#uml->>ok good
14:41<newbie-#uml->>I wonder if it did for version 2.6.12.6
14:41<jdike-#uml->>no
14:42<newbie-#uml->>I am just reviewing the basics, since the uml guest kernel I built last night seeks to kernel panic immediately with a weird error that google and wiki don't seem to have helpful info on...I may do a fresh build before I ask for assistance
14:42<jdike-#uml->>build 2.6.23
14:43<newbie-#uml->>Can I use that with a root image from 2.6.12?
14:43<newbie-#uml->>I suspect the modules may not work
14:44<jdike-#uml->>an old root filesystem should be fine
14:44<newbie-#uml->>ok then :-) 2.6.23 it is ..back in a bit
14:44<newbie-#uml->>thanks
14:57|-|dang [~dang@adsl-75-45-211-249.dsl.sfldmi.sbcglobal.net] has quit [Read error: Connection reset by peer]
14:58|-|dang [~dang@adsl-75-45-211-249.dsl.sfldmi.sbcglobal.net] has joined #uml
15:01|-|mjf [~mjf@r5bb59.net.upc.cz] has joined #uml
15:01<mjf-#uml->>Hello.
15:01<mjf-#uml->>May I ask a short question?
15:02<Magotari-#uml->>mjf: Sure.
15:02<jdike-#uml->>what if I said no?
15:03<jdike-#uml->>what if it had to be a long question?
15:03<jdike-#uml->>what if it had to involve giraffes?
15:03<mjf-#uml->>I appended to UM... ubda=/path/to/cow,/path/to/image_with_partitions root=/dev/ubda1 (I created the /dev/ubdaX devices inside the UM image) and while starting the ext3fs is complaining about reading beyond the partition end. :(
15:03<jdike-#uml->>no giraffes there
15:03<jdike-#uml->>pretty long though
15:03<mjf-#uml->>jdike: but I like giraffes :)
15:04<Magotari-#uml->>Did you do something to the image? Like resize partitions, dd something... Anything?
15:04<jdike-#uml->>I would fsck the thing
15:04<mjf-#uml->>nothing
15:05<mjf-#uml->>I can easily mount the partitions inside using -oloop,offset=N
15:05<Magotari-#uml->>So would I, really. fsck it is. Especially with cow files present, just in case.
15:05<jdike-#uml->>it worked on one boot, and on the next, it starts complaining?
15:06<mjf-#uml->>No fsck is needed. The partition was created using dd, mkfs.ext3'ed and mounted and then cdebootstrapped. The second partition is swap partition.
15:06<jdike-#uml->>I would fsck -f the thing
15:06<mjf-#uml->>on first it is complaining...
15:06<jdike-#uml->>this had never been booted before?
15:06<mjf-#uml->>I think I messed up the /dev/ubdX files inside...
15:06<jdike-#uml->>no
15:07<Magotari-#uml->>mjf: Did the system ever boot right?
15:07<jdike-#uml->>unless you messed up the minor numbers
15:07<mjf-#uml->>/mnt/dev/ubd0 98,0, /mnt/dev/ubd1 98,1 etc...
15:07<Magotari-#uml->>:/
15:07<mjf-#uml->>is this correct?
15:07<Magotari-#uml->>Nope. Bad numbers.
15:07<mjf-#uml->>??
15:07<mjf-#uml->>wtf?
15:07<jdike-#uml->>we like ubda, ubdb, etc now, but that's fine
15:07<Magotari-#uml->>ubda1 is 98 and 16
15:07<mjf-#uml->>aha!
15:07<mjf-#uml->>I misunderstood the docu...
15:07<mjf-#uml->>thanks, I will try...
15:07<Magotari-#uml->>If I remember right, anyway.
15:08<Magotari-#uml->>Look at the list of devices.
15:08<mjf-#uml->>yes, that was the docu..
15:08<mjf-#uml->>;)
15:08<Magotari-#uml->>THe current kernel's documentation has it right.
15:08<mjf-#uml->>yes, I was reading the current but must have misunderstood it...
15:08<Magotari-#uml->>Hmm...
15:08<Magotari-#uml->>Wait.
15:08<Magotari-#uml->>Now, do I have it right myself?
15:08<jdike-#uml->>what's 98,1 then
15:08<Magotari-#uml->>Yeah, exactly.
15:08[~]Magotari #uml burns in shame.#uml-> burns in shame.
15:08<jdike-#uml->>that should be ubda1
15:09<mjf-#uml->>ubda1 is 98,1
15:09<Magotari-#uml->>Ok, so I give up. Over to you Jeff. I will shut up.
15:09<mjf-#uml->>So Ihave correct?
15:09<jdike-#uml->>I don't use partitioned devices, so I'm not positive
15:09<Magotari-#uml->>Yeah, looks like it. /me curses at self.
15:09<jdike-#uml->>but I think you're right
15:10<mjf-#uml->>so, the ubda is 98,0
15:10<jdike-#uml->>brw-r----- 1 root disk 98, 0 Oct 23 14:00 /dev/ubda
15:10<jdike-#uml->>brw-r----- 1 root disk 98, 16 Oct 23 14:10 /dev/ubdb
15:10<jdike-#uml->>so the partitions of ubda would be 98,1...15
15:10<Magotari-#uml->>So ubda1 is 98,1.
15:10<Magotari-#uml->>Yes, that adds up so far.
15:11|-|netdrake [netdrake@rootshell.sk] has quit [Ping timeout: 480 seconds]
15:11<mjf-#uml->>I see now where's the problem...
15:11|-|krau [~cktakahas@200.184.118.132] has quit [Read error: Operation timed out]
15:11|-|dang [~dang@adsl-75-45-211-249.dsl.sfldmi.sbcglobal.net] has quit [Quit: Leaving.]
15:11<mjf-#uml->>One moment please, I need to re-generate the ubdX stuff...
15:13<mjf-#uml->>No, s**t :( still complaining... unable to read inode block blah blah attempt to access beyond end of device :(
15:13<mjf-#uml->>I will try to fsck it...
15:13<Magotari-#uml->>So the thing never booted? Not once?
15:14<mjf-#uml->>On host system I see in dmesg: general protection eip:some_hex es["some_hex error:0
15:14<mjf-#uml->>But I can easily mount it with no error or warning...
15:14<jdike-#uml->>did you debootstrap onto ubda or something?
15:14<newbie-#uml->>hmm kernel 2,6,23, root fs: root_fs.fc-3-base.x86_64.pristine.20050606
15:14<mjf-#uml->>Ok, I will try to fsck it.
15:14<mjf-#uml->>cdebootstrap
15:15<newbie-#uml->>seems to loop rebooting continuously just after warning about not able to create console
15:15<jdike-#uml->>whatever, I assume it's similar
15:15<mjf-#uml->>to be precise, cdebootstrap -f minimal
15:15<newbie-#uml->>(i think someone said or I read that that warning is harmless)
15:15|-|krau [~cktakahas@200.184.118.132] has joined #uml
15:15<jdike-#uml->>newbie, what's the host?
15:15<newbie-#uml->>2.6.12-6_FC3aslsmp
15:16<Magotari-#uml->>mjf: Does UML work normally, other than the case here?
15:16<newbie-#uml->>64 bit
15:16<jdike-#uml->>any chance you could get a newer kernel there?
15:17<mjf-#uml->>Magotari: it work with 2.6.22.something...
15:17<newbie-#uml->>maybe... it's not my machine and kind of in use for other things like testing here at work.
15:17<mjf-#uml->>Magotari: now I switched host and um to 2.6.23.1
15:17<Magotari-#uml->>So you updated your kernels and it shopped working?
15:17<Magotari-#uml->>*stopped
15:18<jdike-#uml->>there have been some host bugs on x86_64 which affected UML
15:19<Magotari-#uml->>mjf: Did you refer to just this one case breaking after the update, or did UML in general stop working on your system?
15:19<newbie-#uml->>jdike: ahh ok...let me see if I can find a machine to upgrade
15:19<mjf-#uml->>Magotari: to be precise, I erased kernels, compiled new, erased old and dirty images, created new and tried to run again... :(
15:19|-|rjbell4 [~bbell@c-75-67-251-249.hsd1.nh.comcast.net] has left #uml []
15:19<jdike-#uml->>getting rid of old, working stuff is sometimes not the best idea :-)
15:19<mjf-#uml->>Magotari: the same step-by-step worked before, strange...
15:20<mjf-#uml->>hell, fsck does not know offset, I will need to use losetup ;)
15:20<mjf-#uml->>what a fun :)
15:20<Magotari-#uml->>mjf: So, did all UML fail or did just this one?
15:20<Magotari-#uml->>The one which we are dealing with now?
15:21<jdike-#uml->>you can boot init=/bin/bash and run fsck from inside UML
15:21<jdike-#uml->>assuming the filesystem works enough to read fsck into memory
15:21<mjf-#uml->>Magotari: I use the same step-by-step when creating the old ones, they worked... this new one ends in infinite loop and writes pretty quickly the above error message...
15:21<mjf-#uml->>I am doing the fsck now...
15:22<mjf-#uml->>No error or problem found on the ubda1 partition...
15:22<Magotari-#uml->>mjf: Can you get the kernel from the UML website and try with it?
15:22<jdike-#uml->>fsck -f?
15:22<jdike-#uml->>i.e. it's really looking at the disk?
15:23<mjf-#uml->>yes
15:23<mjf-#uml->>I use mount-raw.awk script which workes correctly to calculate the proper offset...
15:23<mjf-#uml->>http://vger.cz/hacks/awk/mount-raw.awk
15:24<mjf-#uml->>Really, this script *works* (somehow magically) :)
15:24<mjf-#uml->>If DEBUG=1 then just prints the commandline to mount. if DEBUG=0 it really does the mount.
15:25<Magotari-#uml->>If it worked fine with the old kernels I would not blame the fs but the only thing which changed, the kernels...
15:25<Magotari-#uml->>But I am kinda lost as to when it worked or not anymore.
15:25<mjf-#uml->>To be precise, I an not sure, but now when looking my old startup scripts, it seems I used separate partition images. :(
15:25<mjf-#uml->>Ok, well, my fault.
15:26<mjf-#uml->>But still, I would like to use just one image with several partitions inside. It is possible with UML or not? Perhaps there is really some fault in my configs or /dev/ubdX files...
15:27<mjf-#uml->>Point me to some working image please, I will try it...
15:27<Magotari-#uml->>Possible, no problem with that. I work like that a lot, creating images with qemu and a livecd.
15:27<Magotari-#uml->>Now, a working image? Hmm...
15:28<mjf-#uml->>You suggested one before (or perhaps not you but somebody else). Is it on UML pages?
15:28<Magotari-#uml->>Did you try booting with init=/bin/bash?
15:28<mjf-#uml->>If Ican not mount / how could I do /bin/bash? ;)
15:28<Magotari-#uml->>I did, for sanity checking I usually tell people to get the fs and kernel from the uml website, because they usually work well.
15:29<Magotari-#uml->>Well, init=/bin/bash works quite often when fsck complains.
15:29<Magotari-#uml->>Sometimes anyway.
15:29<mjf-#uml->>OK, will try...
15:29<Magotari-#uml->>Ok, let me find you an image...
15:30<mjf-#uml->>Attempted to kill init, kernel panic... I tried to chroot inside the mounted image before and /bin/sh worked as charm...
15:30<Magotari-#uml->>:/
15:30<Magotari-#uml->>Bizzare.
15:30<mjf-#uml->>So it must be something about the image itself or about the uml/ext3 code or something...
15:31<mjf-#uml->>Perhaps I should try the old method with separated partitions...
15:31<mjf-#uml->>We will see..
15:31<Magotari-#uml->>http://uml.nagafix.co.uk/
15:31<Magotari-#uml->>Here are lots of images to choose from. They seem to be single partition from what I see, but maybe one or two are full images.
15:32<mjf-#uml->>^^ a poisonous code resides inside :-) (just joking)
15:32<Magotari-#uml->>If you could test if one of those boots, that would be great. Just simple boot, nothing fancy.
15:32<mjf-#uml->>how big are they?
15:32<Magotari-#uml->>The smallest one I see is 45M.
15:33<mjf-#uml->>which one is it?
15:33<mjf-#uml->>I do not see sizes on the page :(
15:33<Magotari-#uml->>Damn small linux.
15:33<mjf-#uml->>ok
15:33<Magotari-#uml->>By clicking on the name of the distro you get details.
15:34<mjf-#uml->>aha
15:34<mjf-#uml->>ok
15:36<mjf-#uml->>5 minutes to be downloaded... :( I am not at work now so my line is pretty lazy...
15:36<mjf-#uml->>My local provider is hell...
15:36<Magotari-#uml->>Ouch.
15:36<mjf-#uml->>yes.
15:37<mjf-#uml->>I have 10ge reduced to 1ge (my network card) to tranzit at work, but at home I have 100ms latencies! Really, hell. :(((
15:38<Magotari-#uml->>Yeah, quite painful.
15:39<Magotari-#uml->>I think I have an idea now.
15:39<mjf-#uml->>Never get use to high bandwidths. Not because you needed it. You really will *never* use such speed. But latencies beyond 0.1ms are good thing. One can easily get used to it. ;) Anything else is then painful.
15:39<mjf-#uml->>What idea?
15:39<Magotari-#uml->>Did you modify the rootfs without cow files?
15:39<Magotari-#uml->>I mean, loopback mounted the fs, changed something?
15:39<mjf-#uml->>yes
15:40<Magotari-#uml->>Ouch.
15:40<mjf-#uml->>I need to loop it to mount it.
15:40<Magotari-#uml->>The cow files are toast if you change a rootfs.
15:40<Magotari-#uml->>UML should complain about it.
15:40<mjf-#uml->>I will erase the cow.
15:41<Magotari-#uml->>If you need to change the rootfs by loopback mounting, first merge your cow files into it.
15:41<Magotari-#uml->>UML should protest when the mtime of cow files does not match the mtime of the rootfs file...
15:42<mjf-#uml->>yep
15:42<mjf-#uml->>but that was not the case
15:42<mjf-#uml->>I tried to start it up without cow and the result is the same
15:42<Magotari-#uml->>Oh boy.
15:42<Magotari-#uml->>Puzzling indeed.
15:42<mjf-#uml->>What I am woriing about is the infinite loop!
15:42<mjf-#uml->>That (!) is strange.
15:43<mjf-#uml->>It loops at same inode num.
15:43<mjf-#uml->>It should not, right?
15:43<mjf-#uml->>It should report that the inode is beyond and then give up.
15:43<mjf-#uml->>Or am I wrong?
15:43<Magotari-#uml->>No idea about that. I don't know. jdike?
15:43<mjf-#uml->>jdike: ?
15:44<mjf-#uml->>jdike: wanna do some kernel debugging with me again :)
15:44<mjf-#uml->>jdike: (was it you ro not? somebody here tried to teach me howto debug kernel months ago).
15:45<mjf-#uml->>jdike: <- an infine loop on the same inode number, very interesting for you I guess...
15:47<mjf-#uml->>jdike: the same inode, looping between two block numbers...
15:48<newbie-#uml->>jdike: I was unable to find a 2.6.23 machine or one I could upgrade. I did find a 2.6.22.9-91.fc7 machine and tried my guest kernel there - it still loops. After "Warning: unable to open an initial console." it says "Restarting system" and reboots the guest - this continues
15:48|-|kos_tom [~thomas@col31-3-82-247-183-72.fbx.proxad.net] has quit [Remote host closed the connection]
15:50|-|netdrake [netdrake@2001:5c0:904b:ffff::1] has joined #uml
15:50<mjf-#uml->>Magotari: The DSL works.
15:50<Magotari-#uml->>Ok. So your kernels are fine. Something is borked with the rootfs.
15:51<mjf-#uml->>Magotari: So there is a problem either with the partition (but what problem it could be?) or the fact that it is in an image and not standalone...
15:51<Magotari-#uml->>I run not standalone things often...
15:51<mjf-#uml->>Magotari: rootfs's fine, no fsck error or warning, mountable...
15:51<mjf-#uml->>Magotari: perhaps I did something wrong.
15:52<mjf-#uml->>Magotari: can you show me your commandline for non-standalone image?
15:52<Magotari-#uml->>I am thinking...
15:52<Magotari-#uml->>Ok.
15:52<Magotari-#uml->>sudo ./linux ubda=/dev/sda3 mem=400M ssl=port:9003 eth0=tuntap,,,192.168.0.4 noprocmm
15:52<Magotari-#uml->>Erm. Wrong one. Where did I put it.
15:52<mjf-#uml->>/dev/sda3 seems like physical image...
15:53<Magotari-#uml->>./linux ubda=kilogram.cow,kilogram.raw mem=32M ssl=port:9000 eth0=tuntap,,,192.168.0.4 root=/dev/ubda1 noprocmm
15:53<Magotari-#uml->>Yeah, physical partition. You can do it, but it is dangerous.
15:53<mjf-#uml->>the same as mine.,
15:53<mjf-#uml->>I know.
15:53<mjf-#uml->>OK.
15:53<mjf-#uml->>Well.
15:53<mjf-#uml->>So there must be bug in method I used to create the image.
15:53<Magotari-#uml->>Erm... I have a question. Did you append a partition table to the thing?
15:54<mjf-#uml->>dd if=/dev/zero of=file bs=1M seek=1024 count=1
15:54<mjf-#uml->>fdisk file
15:54<mjf-#uml->>...
15:54<mjf-#uml->>partioned
15:54<mjf-#uml->>losetup -foloop,offset=...
15:54<Magotari-#uml->>:/
15:54<mjf-#uml->>mount /dev/loop0 /mnt
15:54<mjf-#uml->>cdebootstrap -fminimal etch /mnt
15:54<mjf-#uml->>...
15:55<mjf-#uml->>then I did the mknods inside the /mnt/dev
15:55<mjf-#uml->>umount...
15:55<Magotari-#uml->>Seems fine.
15:55<mjf-#uml->>vmlinux ...
15:55<mjf-#uml->>yes.
15:55<mjf-#uml->>(I forgot, I did also the mkfs.ext3 before the mount ;)
15:55<Magotari-#uml->>Yeah, I imagine that.
15:55<mjf-#uml->>I know.
15:55<mjf-#uml->>Just joking.
15:55<mjf-#uml->>This method is fine, right?
15:56<mjf-#uml->>But the offset is strange.
15:56<mjf-#uml->>Can you show me the offset of you first partition in the image?
15:56<Magotari-#uml->>It seems to be, I just use QEMU to get my nonstanalone images.
15:56<Magotari-#uml->>I don't know it myself. Hell, I don't even know how to get it out. Any hints?
15:56<mjf-#uml->>mount-raw.awk
15:57<Magotari-#uml->>Oh. Right. Why am I so stupid today? :/
15:57<mjf-#uml->>and *LET DEBUG=1 AS IS*
15:57<mjf-#uml->>or look in it how to calculate it...
15:57<mjf-#uml->>I have a suspision...
15:59<mjf-#uml->>To be precise, I used cfdisk (because I am lazy to think sometimes...) and not the real's man fdisk
15:59<mjf-#uml->>But I guess there is no pron against cfdisk.
16:01<Magotari-#uml->>Ok, I have the offset.
16:01<mjf-#uml->>Tell me.
16:01<Magotari-#uml->>32256
16:02<mjf-#uml->>Seems pretty similar.
16:02<mjf-#uml->>So it is not about offsets... :(
16:02<mjf-#uml->>Do you use 2.6.23.1 kernels?
16:02<mjf-#uml->>There were lots of patches about uml...
16:02<mjf-#uml->>so...
16:03<Magotari-#uml->>Hmmm, sorta. I think 2.6.23-rc7 or something for host.
16:03<mjf-#uml->>and uml?
16:03<mjf-#uml->>this is the most important...
16:03<Magotari-#uml->>Guests are cutting edge, as much as I can. 2.6.23-mm1
16:03<mjf-#uml->>-mm, ok.
16:03<Magotari-#uml->>But it needs some patches, so don't get it.
16:04<mjf-#uml->>aha
16:04<Magotari-#uml->>It won't build by default. Try the final 2.6.23 or one of the late rc editions.
16:04<Magotari-#uml->>But I really don't think this is about a kernel anymore.
16:04<mjf-#uml->>I use 2.6.23.1 (latest)
16:04<mjf-#uml->>should be fine...
16:04<Magotari-#uml->>Yeah, should be.
16:04<mjf-#uml->>OK, I will try to create new image from the scratch.
16:04<Magotari-#uml->>Good luck.
16:05<mjf-#uml->>Can you provide me ls -la /dev/ubd[a-z0-9]* from "kilogram" ?
16:05<mjf-#uml->>please?
16:05<mjf-#uml->>Thanks.
16:05<Magotari-#uml->>Yes, sec.
16:05<mjf-#uml->>Put it rather somewhere in pastebin.
16:05<mjf-#uml->>Thanks.
16:06<mjf-#uml->>Just for case I really made some really stupid mistake, but it seems the ext3 gets detected correctly.
16:06<mjf-#uml->>Did you made the first partition "bootable" in the fdisk while creating the image?
16:06<Magotari-#uml->>brw-r--r-- 1 root root 98, 0 2007-10-02 22:32 ubda
16:06<Magotari-#uml->>brw-r--r-- 1 root root 98, 1 2007-10-02 22:32 ubda1
16:06<mjf-#uml->>(but this should not spoin anything...
16:06<mjf-#uml->>)
16:06<mjf-#uml->>s/spoin/spoil/
16:06<Magotari-#uml->>I don't even remember.
16:07<mjf-#uml->>I even should not matter, right...
16:07<Magotari-#uml->>Yes, seems like I set it.
16:07<mjf-#uml->>Strange, strange, I have it the numbers correct.
16:07<mjf-#uml->>Hm.
16:07<Magotari-#uml->>Not the devices, I don't think.
16:07<Magotari-#uml->>Hmm...
16:07<mjf-#uml->>Yes, it really seems it is not about the devices.
16:08<mjf-#uml->>It seems it is not about the partition itself as well.
16:08<Magotari-#uml->>I have a question. How did you exactly create the fs?
16:09<Magotari-#uml->>And same question for sway.
16:09<Magotari-#uml->>*swap
16:09<Magotari-#uml->>I mean just the ext3 and swap parts of the creating process.
16:11<mjf-#uml->>dd if=/dev/zero of=/path/to/file bs=1M count=1 seek=2048; losetup -f /path/to/file; cfdisk /dev/loop0; losetup -d /dev/loop0; losetup -oloop,offset=N /path/to/file; mkfs.ext3 /dev/loop0; mount /dev/loop0 /mnt; cdebootstrap -f minimal etch /mnt; cd /mnt/dev; mknod ...; cd ../..; umount /mnt; losetup -d /dev/loop0; ... and the same for swap...
16:14<mjf-#uml->>I now tried new standalone partition and it works.
16:14<mjf-#uml->>I have to leave now.
16:14<Magotari-#uml->>Ok.
16:14<Magotari-#uml->>See you later.
16:14<Magotari-#uml->>Good luck, come again.
16:14<mjf-#uml->>Tomorrow I will return here and refer about the imaged one atttempt...
16:14<mjf-#uml->>Magotari: goo night.
16:14<mjf-#uml->>and thanks a lot.
16:14<Magotari-#uml->>Sleep well.
16:14<mjf-#uml->>bye.
16:15<mjf-#uml->>you too.
16:15<mjf-#uml->>:)
16:15|-|mjf [~mjf@r5bb59.net.upc.cz] has quit [Quit: leaving]
16:15<Magotari-#uml->>jdike: Argh. Sorry about that minor number disaster. I am trying to help out anyone who comes for it, but I guess I still need to learn more before I should do that.
16:21|-|aroscha [~aroscha@vivilokal.funkfeuer.at] has joined #uml
16:27|-|mjf [~mjf@r5bb59.net.upc.cz] has joined #uml
16:27<mjf-#uml->>um, soory
16:27<mjf-#uml->>back again
16:28<mjf-#uml->>btw, how to "freeze" the umls?
16:28<mjf-#uml->>I would like to suspend to ram now and can not, because "some processes are refusing to freeze" and then I see listing of all the uml threads... ;)
16:29<mjf-#uml->>so it seems I can not hibernate my notebook with running umls?
16:29<mjf-#uml->>It worked before...
16:29<mjf-#uml->>jdike?
16:29<mjf-#uml->>OK, well I have really go to sleep. bye. see you.
16:29<jdike-#uml->>well
16:30<mjf-#uml->>yes?
16:30<jdike-#uml->>why would a UML instance prevent a suspend?
16:30<mjf-#uml->>yes, that's the question...
16:30<jdike-#uml->>it just has files open
16:30<jdike-#uml->>are you sure it's the UMLs?
16:30<mjf-#uml->>ok, but in some older kernels it was possible and worked fine...
16:31<mjf-#uml->>yes, because s2r gives you listing of the processes that are not freezable...
16:31<jdike-#uml->>did it actually point at the UML threads as the ones refusing to suspend?
16:31<jdike-#uml->>hmm
16:31<mjf-#uml->>yes
16:31<mjf-#uml->>precisely
16:31<jdike-#uml->>but it doesn't tell you why?
16:31<mjf-#uml->>no
16:31<jdike-#uml->>which ones?
16:31<mjf-#uml->>just 8 processes refused to freeze... waitng 20 seconds etc...
16:31<mjf-#uml->>blah blah...
16:32<mjf-#uml->>aha, it shows no pids :(
16:32<jdike-#uml->>so not all UML threads then
16:32<mjf-#uml->>but I have just 1 uml (8 processes) running at the moment...
16:32<jdike-#uml->>just a small selection
16:32<mjf-#uml->>if I halt it, it is ok.
16:32<mjf-#uml->>If it is running, I can not suspend or hibernate
16:33<jdike-#uml->>well, why in general would a thread prevent suspend?
16:33<mjf-#uml->>dunno
16:33<mjf-#uml->>tell me
16:33<mjf-#uml->>:)
16:33<jdike-#uml->>beats me
16:33<mjf-#uml->>OK, if you liek, we can look at it tomorrow together, ok?
16:33<jdike-#uml->>does it list all of the UML threads?
16:33<jdike-#uml->>OK
16:33<mjf-#uml->>yes.
16:34<mjf-#uml->>it does.
16:34<mjf-#uml->>tomorrow I will try to run more instances of uml and we will see what happens...
16:34<mjf-#uml->>OK?
16:34<jdike-#uml->>yup
16:34<mjf-#uml->>But, really, tomorrow...
16:34<mjf-#uml->>bye
16:34<mjf-#uml->>and have a nice dreams (all of you here).
16:34|-|mjf [~mjf@r5bb59.net.upc.cz] has quit [Quit: leaving]
16:36|-|dang [~dang@nemesis.fprintf.net] has joined #uml
16:57|-|tyler29 [~tyler@ARennes-257-1-73-205.w81-53.abo.wanadoo.fr] has quit [Ping timeout: 480 seconds]
17:10|-|aroscha [~aroscha@vivilokal.funkfeuer.at] has quit [Quit: aroscha]
17:14|-|tyler29 [~tyler@ARennes-257-1-71-209.w81-53.abo.wanadoo.fr] has joined #uml
17:26<newbie-#uml->>jdike: making a bit of progress. After installing the 2.6.23 modules onto my FC3 image, I can now "boot" the UML - It seems to hang on "Initializing hardware" but I'm still waiting to see if it's just busy working out the "hardware". My command line options are currently: ubda=fc3master.cow,fc3master.img mem=256M ssl=port:9000 con0=fd:0,fd:1 con=pts
17:26<newbie-#uml->>Oh that message is actually "Initializing Hardware"
17:26<newbie-#uml->>oh which is what I said...never minde
17:27|-|mgross [~mgross@pool-96-225-192-152.ptldor.fios.verizon.net] has joined #uml
17:34|-|tasaro [~tom@ns.theshore.net] has quit [Ping timeout: 480 seconds]
17:35|-|linbot [~supybot@ns.theshore.net] has quit [Ping timeout: 480 seconds]
17:36<newbie-#uml->>jdike: looks like this really is a hang - still no change. Any ideas?
17:37|-|VS_ChanLog [~stats@ns.theshore.net] has joined #uml
17:38|-|linbot [~supybot@ns.theshore.net] has joined #uml
17:39|-|caker [~caker@caker.netrep.oftc.net] has joined #uml
17:41<newbie-#uml->>of course ideas from others are welcome too...
17:43|-|aroscha [~aroscha@chello213047053193.30.11.tuwien.teleweb.at] has joined #uml
17:46|-|tasaro [~tom@ns.theshore.net] has joined #uml
18:16|-|Baltam8 [~WIKIMOKI@tor-irc.dnsbl.oftc.net] has quit [Ping timeout: 480 seconds]
18:29|-|tyler29 [~tyler@ARennes-257-1-71-209.w81-53.abo.wanadoo.fr] has quit [Ping timeout: 480 seconds]
19:49|-|mgross [~mgross@pool-96-225-192-152.ptldor.fios.verizon.net] has quit [Ping timeout: 480 seconds]
20:09|-|VS_ChanLog [~stats@ns.theshore.net] has joined #uml
20:26|-|Baltam8 [~WIKIMOKI@tor-irc.dnsbl.oftc.net] has joined #uml
21:01|-|hfb [~hfb@pool-71-106-219-180.lsanca.dsl-w.verizon.net] has quit [Quit: Leaving]
21:31|-|aroscha [~aroscha@chello213047053193.30.11.tuwien.teleweb.at] has quit [Quit: aroscha]
21:33|-|aroscha [~aroscha@chello213047053193.30.11.tuwien.teleweb.at] has joined #uml
21:41|-|aroscha [~aroscha@chello213047053193.30.11.tuwien.teleweb.at] has quit [Quit: aroscha]
22:07|-|Nem^ [~Nem@dslb-084-056-248-124.pools.arcor-ip.net] has quit [Ping timeout: 480 seconds]
22:17|-|Nem^ [~Nem@dslb-084-056-252-225.pools.arcor-ip.net] has joined #uml
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 Wed Oct 24 00:00:54 2007