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

---Logopened Mon Apr 09 00:00:28 2007
00:07|-|aroscha [] has quit [Quit: aroscha]
01:55|-|shze [] has joined #uml
02:24|-|shze [] has left #uml [Konversation terminated!]
02:30|-|shze [] has joined #uml
02:31|-|shze [] has left #uml []
02:32|-|shze [] has joined #uml
02:33|-|aroscha [~aroscha@] has joined #uml
02:38|-|shze [] has left #uml [Konversation terminated!]
02:39|-|shze [] has joined #uml
02:51|-|aroscha_ [~aroscha@] has joined #uml
02:51|-|aroscha [~aroscha@] has quit [Ping timeout: 480 seconds]
03:00|-|aroscha_ [~aroscha@] has quit [Quit: aroscha_]
03:20|-|aroscha [] has joined #uml
03:26|-|tommie [~tommie@] has joined #uml
03:30|-|aroscha [] has left #uml []
04:56|-|tommie [~tommie@] has quit [Quit: Leaving]
05:35|-|mheinzes [] has joined #uml
05:39|-|shze [] has quit [Ping timeout: 480 seconds]
07:50|-|krau [~cktakahas@] has joined #uml
08:00|-|orionrobots [~danny@] has joined #uml
08:29|-|tarflong [] has quit [Quit: Doggon, kicked again!]
08:43|-|dgraves [] has joined #uml
08:47|-|mheinzes [] has left #uml [Konversation terminated!]
08:54|-|pat_ [] has joined #uml
08:55<pat_>hello .. hmm where's jdike? :)
08:59<pat_>well it's about some urgent uml bug
09:00<pat_>must be something with the ethN naming of the guest kernel .. commandline option simply gets ignored and right at the moment I have a eth19 in my UML
09:00<pat_>although it's supposed to be eth0 just like my 1st uml instance
09:01<pat_>here a user has a similar problem
09:05<dgraves>pat_: what's your command line?
09:06<pat_>Kernel command line: ubd0=/dev/md0 devfs=nomount eth1=tuntap,uml2-conn0 con0=fd:0,fd:1 mem=64M root=98:0
09:07<pat_>as I said .. eth19 appears in ifconfig -a
09:07<pat_>before it was eth18 .. seems with every shutdown / restart it increases
09:07<dgraves>pat_: i'd expect to see eth1, not eth19.
09:07<pat_>dgraves: indeed
09:07<pat_>but eth19 is working fine
09:07<pat_>read up on th elink I pasted above
09:07<dgraves>i did.
09:07<pat_>the user had the same problem
09:07<dgraves>its curious. :)
09:07<pat_>and jdike seems to k now about atleats one other user/case
09:07<pat_>where that problem appeared
09:08<dgraves>well, give him a ping in a couple of hours, most likely> :)
09:08<pat_>currently using 2.6.21-rc6 without skas patches
09:08<pat_>heh yea I will .. I hope I can help solving this .. probably that'll mean loads of kernel recompiling just on debug purpose .. but well I have time and I am trying to be hepful for such a great piece of software :)
09:35<orionrobots>OK - I have a problem of a disappearing device. Ubdb - the second device does not always (in fact mostly does not) appear in the /dev/ filesystem, however, it is in /proc/diskstats.
09:36<orionrobots>My command line is : linux-2.6.21 con=null con0=null,fd:2 con1=fd:0,fd:1 ubd0=./root_fs ubd1=swap eth0=tuntap,,, mem=256M
09:37<orionrobots>The root fs is Edgy. The image swap is "Linux/i386 swap file (new style) 1 (4K pages) size 131071 pages"
09:48<orionrobots>The only message about the device in dmesg, syslog or messages is thus: "Apr 9 14:16:58 uml-ubuntu kernel: ubdb: unknown partition table", which appears to be a red herring, as ubda (which is there all the time) has exactly the same message "Apr 9 14:16:58 uml-ubuntu kernel: ubda: unknown partition table".
09:48<orionrobots>Trying "MAKEDEV" as root does not affect it.
09:50<orionrobots>Querying it with the mconsole:
09:50<orionrobots>(/home/danny/.u) config ubda
09:50<orionrobots>OK ./root_fs
09:50<orionrobots>(/home/danny/.u) config ubdb
09:50<orionrobots>OK swap
10:15|-|pat__ [~pat@] has joined #uml
10:21|-|pat_ [] has quit [Ping timeout: 480 seconds]
10:23|-|dgraves [] has quit [Remote host closed the connection]
10:24<orionrobots>Hmm - hold on (seem to be helping myself out here), there is one difference - that "./" - not sure if that will change it. If I change the command line to use ./swap, then it works. Ok - problem solved...
10:37|-|aroscha [~aroscha@] has joined #uml
10:39<aroscha>question: I tried to repeat patching kernel with blaisorblade's latest skas-2.6.20-v9-pre9 on a AMD 64 machine. No success!
10:39<aroscha>[root@texas linux]# make ARCH=um
10:39<aroscha> CC arch/um/kernel/ptrace.o
10:39<aroscha>arch/um/kernel/ptrace.c: In function â:
10:39<aroscha>arch/um/kernel/ptrace.c:204: error: invalid application of â to incomplete type â
10:39<aroscha>arch/um/kernel/ptrace.c:212: error: storage size of â isnât known
10:39<aroscha>arch/um/kernel/ptrace.c:212: warning: unused variable â
10:39<aroscha>make[1]: *** [arch/um/kernel/ptrace.o] Error 1
10:39<aroscha>anybody know this?
10:40<aroscha>the devel / host machine is a Linux 2.6.18-1.2747.el5 #1 SMP Sun Dec 10 18:16:48 EST 2006 x86_64 x86_64 x86_64 GNU/Linux
10:40<aroscha>[root@texas linux]#
10:46|-|kos_tom [] has joined #uml
10:46|-|kos_tom_ [] has joined #uml
10:46|-|kos_tom [] has quit [Read error: Connection reset by peer]
10:56|-|hfb [] has joined #uml
10:57|-|hfb [] has left #uml []
11:19|-|pat__ [~pat@] has quit [Quit: leaving]
11:32|-|mjf [] has joined #uml
11:33|-|mjf [] has quit []
11:35|-|jdike [] has joined #uml
11:35<jdike>Hi guys
11:37<kokoko1>Hello jdike
11:38<caker>jdike: ponggggg
11:43<mikegrb>caker: I think your g key is sticking
11:43[~]mikegrb runs
11:48<jdike>wow, long ping time
11:48<jdike>OK, I have a patch for you
11:50<jdike>you'll need ulimit -c to say unlimited
11:50<jdike>apply the patch, boot up a UML, hit the main pid with a SIGSEGV, make sure you get a core, and send me the binary and core file
11:51<jdike>to make sure that I end up with something I can debug when the IO scheduler crashes
11:57|-|ram [] has joined #uml
12:44<jdike>~12-13% kernel build speedup with the patches I'm sending in
12:59|-|kos_tom_ [] has quit [Remote host closed the connection]
13:02|-|kos_tom [] has joined #uml
13:09|-|besonen_mobile_ [] has quit [Ping timeout: 480 seconds]
14:11|-|moyix [] has quit [Ping timeout: 480 seconds]
14:33<caker>jdike: ok, I'll get that to you tonight -- tasaro and I are busy shipping servers, all to run your software!
14:33<caker>check it:
14:45<kokoko1>caker, you work for ?
14:45<kokoko1>or you are the owner :)
14:49<caker>kokoko1: both
14:50<kokoko1>heh right :)
14:55<caker>kokoko1: how dare you not listen to Jeff and my podcast! :) , btw
14:56|-|moyix [] has joined #uml
14:58<kokoko1>caker, lol okay downloading it :-)
15:03<jdike>you are some busy beavers
15:03|-|aroscha [~aroscha@] has quit [Quit: aroscha]
15:04<jdike>I'd be worried about dropping 3 or 4 of those on the highway
15:04|-|asdf [] has joined #uml
15:05<asdf>hello world! anyone having an uml setup on a x86_64 machine?
15:06[~]jdike does
15:07<asdf>mind if I ask you ... what kernels/patches/etc are you using?
15:07<jdike>right now, 2.6.21-rc6-mm1
15:07<asdf>I have a lot of trouble ... finding the right way to do it :)
15:07<jdike>but that's the wrong question
15:07<jdike>anything recent should work
15:07<asdf>like..., or
15:08<jdike>so the right question is, when I run any recent UML on x86_64, bad thing X happens
15:08<jdike>so tell me what value of X you have
15:08<asdf>I can't compile it... I can't run pre-built binaries...
15:09<jdike>let's start with the compilation
15:09<jdike>exactly what do you do
15:09[~]kokoko1 listing to jdike atm :D
15:09<kokoko1>caker, thanks for the link
15:09<jdike>listen to caker
15:09<jdike>that's prolly way more interesting
15:10<asdf>something like ... defconfig ARCH=um, for instance, then make (witch ARCH=um)... ?
15:10<asdf>also tried skas3-v9-pre9 patches or something, still the same
15:11<jdike>how about exact command lines?
15:11<jdike>not vague descriptions
15:11<asdf>ok, sorry :)
15:12<asdf>make defconfig ARCH=um; make ARCH=um
15:13<jdike>what are the results?
15:13<asdf>just a second
15:13<asdf>i'll paste it
15:15<jdike>what version are we dealing with BTW?
15:16<asdf> CC arch/um/kernel/ptrace.o
15:16<asdf>arch/um/kernel/ptrace.c: In function Á-?arch_ptraceÁ-?:
15:16<asdf>arch/um/kernel/ptrace.c:204: error: invalid application of Á-?sizeofÁ-? to incomplete type Á-?struct ptrace_faultinfoÁ-?
15:16<asdf>arch/um/kernel/ptrace.c:212: error: storage size of Á-?ldtÁ-? isnÁ-?t known
15:16<asdf>arch/um/kernel/ptrace.c:212: warning: unused variable Á-?ldtÁ-?
15:16<asdf>make[1]: *** [arch/um/kernel/ptrace.o] Error 1
15:16<asdf>make: *** [arch/um/kernel] Error 2
15:16<asdf>what version of?
15:17<jdike>paste on or pastebin or something
15:18<jdike>Can you get a clean tree from and build from that?
15:18<jdike>assuming this has been patched
15:18<asdf>yes, ... would be fine?
15:20<asdf>hm, I just noticed something
15:20<asdf>defconfig prints a lot of these:
15:21<asdf>./tt/linux- trying to assign nonexistent symbol X86_CMPXCHG64
15:22<asdf>for many different symbols...
15:22<jdike>those should be harmless
15:22<asdf>(that's the fresh code from
15:23<asdf> CC arch/um/os-Linux/start_up.o
15:23<asdf>arch/um/os-Linux/start_up.c: In function Á-?start_ptraced_childÁ-?:
15:23<asdf>arch/um/os-Linux/start_up.c:82: error: Á-?PAGE_SIZEÁ-? undeclared (first use in this function)
15:23<asdf>arch/um/os-Linux/start_up.c:82: error: (Each undeclared identifier is reported only once
15:23<asdf>arch/um/os-Linux/start_up.c:82: error: for each function it appears in.)
15:23<jdike>so you just downloaded a fresh tree and did defconfig on it, nothing else?
15:23<asdf>arch/um/os-Linux/start_up.c: In function Á-?stop_ptraced_childÁ-?:
15:23<asdf>arch/um/os-Linux/start_up.c:131: error: Á-?PAGE_SIZEÁ-? undeclared (first use in this function)
15:23<asdf>make[1]: *** [arch/um/os-Linux/start_up.o] Error 1
15:23<asdf>make: *** [arch/um/os-Linux] Error 2
15:23<kokoko1>New Data Center in Atlanta <-- sound cool yeah
15:23<asdf>yes, defconfig, then make
15:23<jdike>OK, hold on
15:26|-|asdf changed nick to asdf_
15:28|-|moyix [] has quit [Ping timeout: 480 seconds]
15:31<jdike>be nice if -mm had a source browser like mainline
15:36<asdf_> CC arch/um/kernel/process.o
15:36<asdf_>arch/um/kernel/process.c:230: error: redefinition of Á-?page_sizeÁ-?
15:36<asdf_>arch/um/kernel/process.c:225: error: previous definition of Á-?page_sizeÁ-? was here
15:36<asdf_>make[1]: *** [arch/um/kernel/process.o] Error 1
15:36<asdf_>make: *** [arch/um/kernel] Error 2
15:36<asdf_>but let me see if i patched it welll
15:37<jdike>if you have two definitions five lines apart, then something went wrong
15:38<asdf_>i guess so :)
15:38<jdike>and one of the points of that patch was to delete that function
15:38<jdike>so if you have two now, something went very wrong
15:49|-|moyix [] has joined #uml
15:56|-|aroscha [] has joined #uml
16:12|-|kos_tom [] has quit [Quit: I like core dumps]
16:38<asdf_>jdike, still there?
16:41|-|Nem^1 [] has joined #uml
16:44|-|Nem^ [] has quit [Read error: Operation timed out]
16:44|-|Nem^1 changed nick to Nem^
16:47<asdf_>patching file arch/um/kernel/process.c
16:47<asdf_>Reversed (or previously applied) patch detected! Assume -R? [n]
16:48<asdf_>that's on a fresh
16:48|-|filip [] has quit [Quit: leaving]
16:48<jdike>what patch are you applying?
16:48<jdike>the page_size one?
16:48<asdf_>6LSvSw51.txt, yes, the one from the web
16:50<jdike>OK, I guess that's in .6
16:50<jdike>I didn't remember
16:50<jdike>hold on
16:50<asdf_>well, other files get patched...
16:50<asdf_>but not this one
16:51<jdike>i.e. the patch applied successfully?
16:51<asdf_>until it reaches arch/um/kernel/process.c
16:52<jdike>OK, with a clean, you have problems in start_up.c, correct?
16:52<asdf_>wait, I'll paste it again
16:52<jdike>Because it is full of PAGE_SIZE
16:52<jdike>don't bother
16:53<asdf_>the patch actually replaces PAGE_SIZEs with KERN_UML_PAGE_SIZE_OR_SOMETHING_LIKE_THAT, right?
16:53<asdf_>and nothing more?
16:54<jdike>OK, that does not patch cleanly
16:55<asdf_>seems so, but I can't figure out why?
16:56<jdike>because it's not against 2.6.20, which is what basically is
16:56<jdike>it's against rcx-mmy
16:56<jdike>but normally things go in more cleanly than this
16:56<aroscha>what is rcx-mmy?
16:57<jdike>right now, we're at 2.6.21-rc6-mm1
16:58<aroscha>ah ok, just had to fill in the vars :)
16:58<jdike>asdf_, the patch does more than that
16:58<jdike>but that's the idea
16:59<jdike>asdf_, what's the host distro?
17:00<jdike>bleeding edge?
17:00<jdike>updated every hour?
17:01<asdf_>well, it was installed a week or so... ago... hasn't been updated AFAIK ... only the kernel go to at some point of time :)
17:01<asdf_>(centos is 4.92)
17:02<jdike>OK, just wondering how common this is, and whether I should get this patch in
17:02<jdike>the patch isn't actually all that bad
17:03<jdike>you said Y when it asked about the reversed patch
17:03<jdike>so it added page_size instead of deleting it
17:03<asdf_>well, you're the expert :)
17:06<jdike>try that
17:07<asdf_>on a fresh
17:10<asdf_> CC arch/um/os-Linux/start_up.o
17:10<asdf_>arch/um/os-Linux/start_up.c: In function Á-?start_ptraced_childÁ-?:
17:10<asdf_>arch/um/os-Linux/start_up.c:82: error: Á-?PAGE_SIZEÁ-? undeclared (first use in this function)
17:10<asdf_>arch/um/os-Linux/start_up.c:82: error: (Each undeclared identifier is reported only once
17:10<asdf_>arch/um/os-Linux/start_up.c:82: error: for each function it appears in.)
17:10<asdf_>arch/um/os-Linux/start_up.c: In function Á-?stop_ptraced_childÁ-?:
17:10<asdf_>arch/um/os-Linux/start_up.c:131: error: Á-?PAGE_SIZEÁ-? undeclared (first use in this function)
17:10<asdf_>make[1]: *** [arch/um/os-Linux/start_up.o] Error 1
17:10<asdf_>make: *** [arch/um/os-Linux] Error 2
17:13<aroscha>jdike: i am reproducing this error on a kernel
17:13<aroscha>with a stock kernel we have the same compile error message (on CentOS)
17:14<aroscha>WITH the patch ( patch -p1 < gUJhpm31.txt ) I am getting the same error message _also_
17:14<jdike>I'm going to have to disappear in the not-too-distant future
17:14<aroscha>so my assumption is that the patch does exactly nothing with PAGE_SIZE
17:15<jdike>just to let you know...
17:15<aroscha>ok, no problem...
17:15<aroscha>any way that we can help to reproduce the bug?
17:15<aroscha>in the mean time?
17:15<aroscha>or any other way that you know which version we could use on AMD64?
17:16<aroscha>actually pentium 64 bit
17:18<jdike>2.6.21-rc6-mm1 should be OK
17:18<aroscha>ok... will try that!
17:18<jdike>well, I don't have a host with this problem, so no guarantees
17:18<jdike>but it should be closer
17:18<aroscha>and in case we two can contribute anything please let us know
17:18<aroscha>you can cross check on ours if you want
17:18<aroscha>as soon as you have some time of course that is
17:19<aroscha>well, i will report
17:23<jdike>apply that on top of what you already have
17:23<jdike>just generated, completely untested...
17:26<aroscha> CC arch/um/os-Linux/skas/mem.oarch/um/os-Linux/skas/mem.c:59:2: warning: #warning Need to look up userspace_pid by cpuarch/um/os-Linux/skas/mem.c: In function ‘run_syscall_stub’:arch/um/os-Linux/skas/mem.c:140: error: ‘PAGE_MASK’ undeclared (first use in this function)arch/um/os-Linux/skas/mem.c:140: error: (Each undeclared identifier is reported only oncearch/um/os-Linux/skas/mem.c:140: error: for each function it ap
17:26<aroscha>same prob
17:26<aroscha>but now on the skas/mem.c file
17:26<aroscha>line 140
17:37|-|krau [~cktakahas@] has quit [Read error: Operation timed out]
17:43<aroscha>ha! jdike: I think we are coming closer to the problem: I tried make ARCH=um defconfig; make ARCH=um on a stock 2.6.21-rc6 kernel and ... I get the same thing:
17:43<aroscha> CC arch/um/os-Linux/start_up.oarch/um/os-Linux/start_up.c: In function ‘start_ptraced_child’:arch/um/os-Linux/start_up.c:110: error: ‘PAGE_SIZE’ undeclared (first use in this function)arch/um/os-Linux/start_up.c:110: error: (Each undeclared identifier is reported only oncearch/um/os-Linux/start_up.c:110: error: for each function it appears in.)arch/um/os-Linux/start_up.c: In function ‘stop_ptraced_child’:arch/um/
17:44<aroscha>can this be connected to some kind of CentOS compile problem?
17:44<aroscha>or wrong .h files or so?
17:45<jdike>more like updated headers which are more carefully cleaned than before
17:45<jdike>this patch is in -mm, not in rc6
17:45<jdike>so if you want to play with versions, try -rc6-mm1
17:46<aroscha>oops yes of course
17:47<aroscha>forgot that
17:47<aroscha>so lets try again
17:48<aroscha> 311 make ARCH=um mrproper 312 make mrproper 313 patch -p1 < ../2.6.21-rc6-mm1 314 make ARCH=um defconfig 315 make ARCH=um 316 history
17:49<aroscha>same problem with start_up.c line 110
17:49<aroscha>arch/um/os-Linux/start_up.c:110: error: ‘PAGE_SIZE’ undeclared (first use in this function)arch
17:59|-|orionrobots [~danny@] has quit [Quit: Leaving.]
18:06|-|asdf_ [] has quit []
18:28<jdike>in rc6-mm1, there are no occurrences of PAGE_SIZE in start_up.c
18:30<aroscha>very strange
18:30<aroscha>i downloaded the stuff from *
18:31<aroscha>and patched with -p1 the 2.6.21-rc6-mm1 patch file
18:32<aroscha>maybe i am making realy stupid mistakes but I doubt it. Ok, in the meantime I was trying to find out if my CentOS and my machine is the cause. I tried all pre compiled kernels from downwards
18:32<aroscha>the kernel with works immediately is
18:33<aroscha>it finds the SKAs3 patch and everything except for the /dev/anon (which is really missing, ok)
18:35<aroscha>concerning the rc6-mm1 PAGE_SIZE thing: I have:
18:35<aroscha>[aaron@texas os-Linux]$ pwd
18:35<aroscha>start_up.c:110: stack = mmap(NULL, PAGE_SIZE, PROT_READ | PROT_WRITE | PROT_EXEC,
18:35<aroscha>start_up.c:114: sp = (unsigned long) stack + PAGE_SIZE - sizeof(void *);
18:35<aroscha>start_up.c:158: if(munmap(stack, PAGE_SIZE) < 0)
18:35<aroscha>start_up.c:538: size = (buf.st_size + UM_KERN_PAGE_SIZE) & ~(UM_KERN_PAGE_SIZE - 1);
18:35<aroscha>start_up.c:547: iomem_size += new->size + UM_KERN_PAGE_SIZE;
18:35<aroscha>so I do have that
18:36<aroscha>kernel was linux-2.6.21-rc6.tar from
18:36<aroscha>and patched with linux-2.6.21-rc6.tar
18:36<aroscha>-rw-r--r-- 1 aaron aaron 25448146 Apr 8 23:09 2.6.21-rc6-mm1
18:36<aroscha>so, I guess that must have been correct
19:01|-|aroscha [] has quit [Quit: aroscha]
19:13|-|ElectricElf [] has quit [Ping timeout: 480 seconds]
19:19|-|ElectricElf [] has joined #uml
19:26|-|aroscha [] has joined #uml
19:29|-|ElectricElf [] has quit [Ping timeout: 480 seconds]
19:36|-|ElectricElf [] has joined #uml
19:56|-|pat_ [] has joined #uml
19:56<pat_>hello jdike :) I've been here several hours ago (when you were not here tho) .. I have a weird problem which you seem to know about already
19:57<pat_>ifconfig -a shows eth20 although the uml is called with eth0
19:57<pat_>and everytime I restart it, it increases by one
19:57[~]caker builds a dump-core kernel
19:58<pat_>this is only occuring with my 2nd uml instance .. the first does not behave like that
19:58<pat_>but it doesn tmatter wether both run at the same time or not .. the 2nd instance always "fails"
19:58<pat_>using 2.6.21-rc6 with no skas patch
20:00<pat_>I'd be pleased if I could help by applying a debug patch or something in order to track down and solve that issue
20:04<caker>pat_: how about NOT using uml-switch alltogether, and going the bridging route?
20:04<pat_>I _am_ using bridging
20:05<pat_>every uml instance has it's own tuntap device .. and is integrated into my NAT .. then gets IP via dhcpd
20:05<pat_>but infact a commandline like:
20:05<pat_>Kernel command line: ubd0=/dev/md0 devfs=nomount eth0=tuntap,uml1-conn1 con0=fd:0,fd:1 mem=64M root=98:0
20:06<pat_>results in the uml having ethN which will icnrease every restart of that instance
20:06<pat_>but not eth0
20:06<pat_>as I said .. I did dig through the channel logs and on 08/15/06 a user had exactly the same problem
20:07<caker>just to verify -- uml1-conn1 is the tap device on the host
20:07<caker>and you're saying that INSIDE UML, on each reboot, it's ethN+1, where N was the previous boot's N?
20:07<caker>that's whack.
20:07<pat_>even Jeff knows about that
20:07<pat_>he mentioned it once himself
20:08<pat_>read up on yourself
20:09<pat_>it's rather hilarious than whack .. since I didnt believe it myself in the first place
20:10<pat_>until I found that log I just pasted above
20:11<pat_>and wlel eth is eth20 atm .. it was eth19 before and eth18 even before that
20:12<pat_>I am even not sure wether this is uml related or not .. but I've never seen that myself nor ever heard of it
20:12<pat_>except when it comes to uml
20:13<caker>what happens to uml1-conn1 between UML reboots on the host?
20:13<pat_>define 'happens'
20:13<caker>does it go away and then get re-created?
20:13<caker>(by you)
20:14<caker>or are you leaving it unchanged between UML reboots
20:14<caker>None of this makes sense, so I'm just trying to get the full picture
20:14<pat_>I leave it unchanged
20:15<pat_>ofc it doesnt make sense
20:15<pat_>but I am experienced enough to see that myself .. which is why I asked for jdike ;)
20:15<pat_>he probably also does not know what's going on
20:15<pat_>but as I sai d.. I am not the first
20:17<pat_>btw was an old kernel command lien I pasted .. but only thing that changed is the device its uml2-conn0 .. my .bash_history was fucke dup .. anyway
20:17<pat_>I rebooted again
20:17<pat_>now it's eth21 :)
20:17<caker>what's the host kernel?
20:18<jdike>someone else figured out what was going, IIRC
20:18<pat_>hm really?
20:18<pat_>enlighten me please :)
20:20<jdike>just looked at the log
20:20<jdike>no one there had any idea what was happening
20:20<jdike>I would guess some hal/udev strangeness
20:21<pat_>same case here except that I noticed that the ethN device number increased by one per reboot
20:22<pat_>which isnt of much use I guess
20:22<jdike>well, I'm guessing there's some sort of state in the filesystem that it's looking at
20:22<jdike>like the ethernet MAC
20:22<jdike>try assigning a MAC
20:23<pat_>then rbeoot and see what happens?
20:23<pat_>right assigned 00:00:00:00:00:01
20:24<pat_>it's eth22 now
20:24<jdike>reboot again with the same MAC
20:25<pat_>eth23 now
20:25<pat_>the mac is lost
20:25<pat_>or well
20:25<jdike>look at dmesg to see why it didn't like it
20:25<pat_>it's got another mac assigned
20:26<jdike>there are various properties that an assigned MAC must have
20:26<jdike>if you give it a bogus one, it will assign a random one
20:27<pat_>hmm nothing about it in dmesg
20:28<jdike>Warning: attempt to assign a globally valid ethernet address to a device
20:28<jdike>You should better enable the 2nd rightmost bit in the first byte of the MAC, i.e. 02:00:00:00:00:01
20:28<jdike>current UMLs have better MAC diagnostics
20:29<pat_>well as I said there was no such error about it
20:30<pat_>anyway .. asigned it and I am currently rebooting the ml
20:30<jdike>current == 2.6.21-rc6-mm1
20:30<pat_>it's eth25 meanwhile and mac got changed
20:30<pat_>ahh hmm
20:30[~]pat_ checks dmesg
20:31<pat_>nope nothing
20:31<pat_>Netdevice 0 (42:24:00:d0:33:ff) : TUN/TAP backend -
20:31<pat_>that is also the current mac
20:32<pat_>of eth25
20:32<jdike>what's your command line?
20:32<pat_>Kernel command line: ubd0=/dev/md0 devfs=nomount eth0=tuntap,uml2-conn0 con0=fd:0,fd:1 mem=64M root=98:0
20:32<jdike>aren't you supposed to be assigning a MAC there?
20:33<pat_>no wonder it changes every reboot
20:33<pat_>wait ;)
20:33<jdike>better hurry before you overflow 32 bits
20:34<pat_>okay while booting netdevice shows the correct assigned mac now
20:34<pat_>eth26 now
20:34<pat_>shall I reboot again?
20:35<jdike>and hope it stays at 26
20:36<pat_>it does
20:36<jdike>now you just need to find the MAC database and nuke it
20:37<pat_>hmm in order to get eth0 again?
20:37<jdike>unless you like eth34734
20:37<jdike>in that case, go wild
20:37<pat_>heh yea .. actually is that behavior supposed to be correct=
20:37<jdike>it kinda makes sense, for a physical box
20:38<pat_>so it's useless wrtiting an uml related patch that would prevent such a behavior?
20:39<jdike>well, yes it is useless
20:39<jdike>unless you propose to patch the distro
20:40<jdike>which would make sense to me
20:40<pat_>there could be some sort of "uml detection"
20:41|-|jdike [] has quit [Quit: Leaving]
20:42|-|aroscha [] has quit [Quit: aroscha]
21:05|-|pat_ [] has quit [Quit: leaving]
21:17|-|shze [] has joined #uml
22:05|-|besonen_mobile [] has joined #uml
22:18|-|ram [] has quit [Ping timeout: 480 seconds]
22:59|-|VS_ChanLog [] has left #uml [Rotating Logs]
22:59|-|VS_ChanLog [] has joined #uml
---Logclosed Tue Apr 10 00:00:46 2007